盤點Linux核心源碼中使用宏定義的若幹技巧（1）

在C中，宏定義的概念雖然簡單，但是真要用好卻并不那麼容易，下面從Linux源碼中抽取一些宏定義的使用方法，希望能從中得到點啟發：

1. 類型檢查

比如module_init的宏定義：

點選(此處)折疊或打開

#define module_init(initfn)                    \

    static inline initcall_t __inittest(void)        \

    { return initfn; }                    \

    int init_module(void) __attribute__((alias(#initfn)));

module_init宏的關鍵點是在代碼中的第4行，通過gcc别名的特性将init_module與initfn等同起來。這裡宏定義的技巧出現在第2和3行，通過return initfn實際上是來對initfn做靜态類型檢查，以確定程式員不會提供一個原型不符合要求的子產品初始化函數，後者要求是一個參數值為void，傳回者為int類型的函數。是以，如果你定義了一個比如void my_module_init(void)或者是void my_module_init(int)這樣的子產品初始化函數作為module_init宏參數，那麼編譯時就會出現類似下面的warning:

GPIO/fsl-gpio.c: In function '__inittest':

GPIO/fsl-gpio.c:46: warning: return from incompatible pointer type

2. 變長參數清單，比如系統調用相關的定義：

#define __SYSCALL_DEFINEx(x, name, ...)                    \

    asmlinkage long sys##name(__SC_DECL##x(__VA_ARGS__))

#define SYSCALL_DEFINEx(x, sname, ...)                \

    __SYSCALL_DEFINEx(x, sname, __VA_ARGS__)

#define SYSCALL_DEFINE1(name, ...) SYSCALL_DEFINEx(1, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE2(name, ...) SYSCALL_DEFINEx(2, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE3(name, ...) SYSCALL_DEFINEx(3, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE4(name, ...) SYSCALL_DEFINEx(4, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE5(name, ...) SYSCALL_DEFINEx(5, _##name, __VA_ARGS__)

#define SYSCALL_DEFINE6(name, ...) SYSCALL_DEFINEx(6, _##name, __VA_ARGS__)

是以源碼中的SYSCALL_DEFINE1(close, unsigned int, fd)将展開成：

asmlinkage long sys_close(__SC_DECL1(unsigned int, fd))

可見，上述宏定義SYSCALL_DEFINE1中除第一個參數明确給出外，對于可變長的參數清單，采用__VA_ARGS__就可以圓滿解決，換言之，__VA_ARGS__成了變長參數清單的容器了。

3.這條也不能算是技巧了，C中宏定義的一種很常見的用法，Linux核心源碼中也大量使用:

  #define STR(x)  #x

#的使用将把宏參數x變成一個字元串，比如STR(my hub)将轉化成"my hub"

另一個常見的符号是##，它用來将兩個參數粘合到一起，比如

  #define STR1(a,b) a##b

那麼STR1(my hub,   is good)将轉換成my hubis good，可見##會自動把第2個參數前的空格給移除掉。

4. do...while(0)這個就不用多說了吧，不過有個問題是，如果使用{...}來代替do{...)while(0)行不行呢？其實呢，大部分情況下都沒有問題，事實上核心源碼中有時候就用一個大括号來代替do...while(0)，是以沒有必然确定的理由說用{...}來代替do...while(0)就一定會有問題，是以我基本上傾向于認為這個隻是個人習慣的不同。事實上如果宏的定義者和使用者能夠注意到此點，就足夠了。