筆者最近看到這樣一篇文章? ，原作者讓 ChatGPT 寫一個內核模塊，要求實現的功能是：每 5 秒向控制臺打印一句 "Hello world"，并且把編譯需要的 Makefile 也一起寫出來。

AI 最開始的實現方法是：創建一個內核線程，線程主體是一個 while 循環，每隔 1 毫秒檢查一次，看時間是不是過去了 5 秒：

?

while (!kthread_should_stop())
{
    unsigned long time_since_load = jiffies - jiffies_at_load;
    unsigned long time_since_load_sec = time_since_load / HZ;
    if (time_since_load_sec >= 5)
    {
        printk(KERN_INFO "Hello world!
");
        jiffies_at_load = jiffies;
    }
    // Sleep for 1 ms to avoid hogging the CPU
    msleep(1);
}

?

此處用 msleep(1) 是沒有大毛病的，它確實可以通過睡眠暫時讓出 CPU，避免 hogging，不像?busy loop?的 mdelay()。

但它這里實現的比較曲折，1 毫秒檢查一次，5 秒內就要檢查 5000 次，雖然沒有「霸占」CPU，但是對 CPU 資源也是不小的浪費。

于是原作者讓它改了一個更減少 CPU 消耗的版本出來：

?

while (!kthread_should_stop())
{
    printk(KERN_INFO "Hello world!
");
    // Sleep for 5 seconds to avoid hogging the CPU
    schedule_timeout(HZ * 5);
}

?

看起來是解決了原來存在的問題，但編譯出來一試，好家伙，"Hello world" 是突突地往控制臺上打啊，根本不是間隔5 秒一次。

把這個問題反饋給 AI 后，它立馬做出了調整，加入了一句對 process 狀態的設置后，就可以 work 了。

?

set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ * 5);

?

查閱 Linux 源碼可知，schedule_timeout() 最終會調用 __schedule() 函數，其對 process 切換的判斷是這樣的：

?

if (!preempt && prev->state)
  deactivate_task(rq, prev, ...);

?

再由于：

?

#define TASK_RUNNING 0x0000

?

所以如果之前的狀態是 RUNNING，process 并不會真的離開 CPU 的 runqueue，豈不就是一直執行，一直框框地打印么。

在 https://livegrep.com/search/linux 上查了下 schedule_timeout() 在內核中的具體使用情況，好些對 set_current_state() 為 INTERRUPTIBLE 的設置沒有和 schedule_timeout() 挨在一起，所以 AI“理解”不了這兩者的關聯，筆者覺得是可以接受的。

不過其實 Linux 是提供了一個“二合一”的封裝函數的：

?

sched schedule_timeout_uninterruptible(signed long timeout)
{
  set_current_state(TASK_UNINTERRUPTIBLE);
  return schedule_timeout(timeout);
}

?

而它還有個更上層的封裝 "msleep"（希望可被信號打斷就用 "msleep_interruptible"）：

?

void msleep(unsigned int msecs)
{
  unsigned long timeout = msecs_to_jiffies(msecs) + 1;
  while (timeout)
    timeout = schedule_timeout_uninterruptible(timeout);
}

?

咳，繞了這么大一圈，其實一開始直接用 msleep(5000) 最方便啦。

后來原作者又提了在「內核模塊」開發中頗為常見的兩點功能：

一是將 5 秒的間隔配置成 module parameter（以供動態調整），這個任務被順利完成了。

二是在 "/proc" 文件系統中加入打印次數的統計功能（以便查詢），這里出了點小岔子，AI 用的 "file_operations"，而不是 "proc_ops"，這在高于 5.7 的內核版本上是編譯不過的（參看筆者親身經歷的這個案例）。

這也不能怪 AI，你沒說內核版本不是。

小結

最后原作者寫了下他的感受，大意就是 "half amazing and half terrifying"，雖然 AI 中途犯了不少錯，但總比自己現查資料來的快不是…

除此之外，筆者也有兩點感受，一是 ChatGPT 即使有時會出錯，但回答地總是非常自信（還好不是那么普通，卻那么自信……），二是那個注釋一條條地寫的真是規范啊，連每個頭文件為什么加，都有理有據，這一點就強過很多人。

?

#include   // Needed for all kernel modules
#include   // Needed for KERN_INFO
#include     // Needed for the macros
#include  // Needed for jiffies
#include    // Needed for msleep

?

筆者自己也用這個題目，在 ChatGPT 上試了一把，得出了不太一樣的結果，欲知后續，請看下文分解。

補充（為了避免影響主線劇情）：

那 schedule_timeout() 返回的時候，也需要手動再將狀態設置回 TASK_RUNNING 么？不需要，因為 timer 的 callback 在喚醒 process 后會將其狀態（自動）設為 RUNNING（參考 Linux 中的等待隊列機制 ）：

?

void process_timeout(struct timer_list *t)
{
  struct process_timer *timeout = from_timer(timeout, t, timer);
  wake_up_process(timeout->task);
}

?