盘点Linux内核源码中使用宏定义的若干技巧-白红宇

盘点Linux内核源码中使用宏定义的若干技巧

阅读量：2456 次

发布时间：2019-05-11

本文共 3522 字，大约阅读时间需要 11 分钟。

2012-07-24 09:50:38

分类：

原文地址：作者：

在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)就一定会有问题，所以我基本上倾向于认为这个只是个人习惯的不同。事实上如果宏的定义者和使用者能够注意到此点，就足够了。

2012-07-24 09:52:49

分类：

原文地址：作者：

5. typeof和0指针

这个在大名鼎鼎的container_of就有出现，事实上一些面试题有时候也喜欢跟这个沾点边。

点击(此处)折叠或打开

#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)

点击(此处)折叠或打开

#define container_of(ptr, type, member) ({
\

const typeof(((type *)0)->member)*__mptr = (ptr); \

(type *)((char *)__mptr - offsetof(type, member)); })

哦，看到没，这里就直接使用了大括号({...})。第一个宏offsetof用来获得一个结构体中某一成员MEMBER与该结构体起始地址的偏移量，这个用法很有创意，0指针，充分利用了编译器的技巧。比如下面的代码，输出的结果是4:

点击(此处)折叠或打开

struct test{

int a;

int b;

};

int main(void)

{

printf("offset_b = %ld\n", (size_t)(&((struct test*)0)->b));

return 0;

}

typeof是gcc对C标准的一个扩展，用来告诉编译器你打算使用括号里面的变量类型。关于typeof的更详细说明请参考：

6. 宏参数的静态检查

下面的宏来自模块参数的定义部分：

点击(此处)折叠或打开

#define __module_param_call(prefix, name, ops, arg, isbool, perm) \

/* Default value instead of permissions? */ \

static int __param_perm_check_##name __attribute__((unused)) = \

BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)) \

+ BUILD_BUG_ON_ZERO(sizeof(""prefix) > MAX_PARAM_PREFIX_LEN); \

static const char __param_str_##name[] = prefix #name; \

static struct kernel_param __moduleparam_const __param_##name \

__used \

__attribute__ ((unused,__section__ ("__param"),aligned(sizeof(void *)))) \

= {
__param_str_##name, ops, perm, isbool ? KPARAM_ISBOOL : 0, \

{
arg } }

其中第3-5行定义了一个事实上并不会用到的变量__param_perm_check_##name，为了防止编译器产生未使用变量的警告，该变量后面使用了__attribute__((unused))属性。这个并不会使用到的变量在该宏中的唯一作用是对变量参数perm和prefix的大小进行一个静态检查，如果BUILD_BUG_ON_ZERO中的条件为TRUE，那么将会产生一个编译错误。

转载地址：http://ntshb.baihongyu.com/

你可能感兴趣的文章

熊猫分发_熊猫cut（）函数示例

查看>>

python中os函数_Python os库函数

查看>>

nodejs fs创建文件_节点FS – NodeJS创建文件，读取文件，写入文件

查看>>

csvreader_OpenCSV CSVReader CSVWriter示例

查看>>

callable线程池示例_Java Callable Future示例

查看>>