Linux kernel coding style （下）

13. 列印 kernel 訊息

kernel開發者喜歡被大家看成是個受過教育的人，所以字要拼對，才能製造這種好印象。不要用一些跛腳的字眼，像是"dont"，要用"do not" 或是 "don't"。訊息文字要扼要 清楚 精確。

kernel訊息文字結尾不需要句點。

列印數字的時候加上括號(%d)是毫無意義的，應該避免。

在linux/device.h中有專為driver提供的巨集，可以方便的印出適合訊息文字，如dev_err() dev_warn() dev_info()。要印出與driver無關的訊息，可以用linux/printk.h中的pr_debug()或是pr_info()。

14. 記憶體配置

kernel中有許多記憶體配置的工具，例如kmalloc() kzalloc() kcalloc() vmalloc()，請參考API文件以了解更多想關資訊。

配置記憶體時，指定記憶體大小的方式如下：

p = kmalloc(sizeof(*p), ...)

用sizeof(struct name)比較難以閱讀，而且若是pointer p的型別改變時，容易因為忘記同步更該型別的名稱而出錯。

把kmalloc的傳回值轉型成void pointer是沒有必要的，C語言已經保證void pointer可以指向任何型別的pointer了。

15. inline傳染病

有些人誤以為gcc中存在種魔法，只要把任何function加上inline，kernel就會跑得更快。亂用inline會造成kernel體積變大，佔去更多cache lines，讓cache效率不彰。kernel體積大也意味只剩更少的記憶體可以給pagecache使用。想想，一有page miss就會耗掉至少5ms，這5ms可以執行有多少instruction啊！

一個基本原則是只要function超過3行，就不用inline。例外是如果某個參數是constant，你知道在compile時就會被最佳化處理掉，那多幾行也無妨。kmalloc inline function是一個很好的例子。

有人又會覺得只會被一個function引用的static function加上inline一定不會對kernel大小造成影響。技術上來說這是正確的，但是對可維護性上來說會有差別。如果有人發現這個inline會造成負面影響大於正面影響，他還要特別去把inline拿掉。

16. function的傳回值與名稱

function表達成功失敗的傳回方法有二，一是傳回錯誤值（-Exxx -> 失敗，0 -> 成功），另一是傳回是否成功的布林值（0 -> 不成功, 非0 -> 成功）

為避免錯誤，kernel中採用此慣例：

• function名為命令式的，如do_something()，則傳回錯誤值
• function名為敘述是的，如is_something(), 則用布林值表達是否成功

若function直接傳回計算結果，則不需比照上述規則。這種情況下使用要利用在合理範圍中的傳回值來代表失敗。常見的例子就是傳回pointer的function用NULL來表示不成功。

17. 不要亂發明已經有的kernel macros

linux/kernel.h中已經有了一堆常用的macro，先看看這再去寫你自己的macro。

18. 文字編輯器專用的指令

有些文字編輯器可以讀取鑲嵌在source code中的指令，以指示該採用某種縮排格式或是辨別檔案類型。例如emacs會用

-*- mode: c -*-

或是

/*
Local Variables:
compile-command: "gcc -DMAGIC_DEBUG_FLAG foo.c"
End:
*/

vim會用

/* vim:set sw=8 noet */

不要在kernel source code中加這些有的沒的東西。這種編輯器的設定是很個人的，每個人用不同編輯器有不同設定，不應該加在source code中。