linux中container_of
linux 驱动程序中 container_of宏解析
众所周知，linux内核的主要开发语言是C，但是现在内核的框架使用了非常多的面向对象的思想，这就面临了一个用C语言来实现面向对象编程的问题，今天我们就来讲讲其中一个例子。
利用结构体中元素指针获取结构体指针
Kobject是linux设备驱动模型的基础，也是设备模型中抽象的一部分。
linux内核为了兼容各种形形色色的设备，就需要对各种设备的共性进行抽象，抽象出一个基类，其余的设备只需要继承此基类就可以了。
而此基类就是kobject(暂且把它看成是一个类)，但是C语言没有面向对象语法。
在C++中这样的操作非常简单，继承基类就可以了，而在C语言中需要将基类的结构体指针嵌入到派生的类中，那么为什么将基类指针嵌入就可以得到派生类的指针呢？
这个实现是一个宏：container_of。
container_of
首先，它的原型是这样的：
#define container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
BUILD_BUG_ON_MSG(!__same_type(*(ptr), ((type *)0)->member) && \
!__same_type(*(ptr), void), \
"pointer type mismatch in container_of()"); \
((type *)(__mptr - offsetof(type, member))); })
被定义于/linux/kernel.h中。
为了阅读和理解的方便，我们在这里先假设基类为Base,而派生类为Derived，显然，派生类Derived中是包含基类Base的定义的，即已知类为Base，未知类为Derived，我们要求解Derived的地址，一个具体的对应就是通过kobject地址求解包含kobject的父结构体的地址，由此我们来逐一分析这个宏的实现。
参数
ptr：ptr是已知基类Base的地址
type: type是派生类的的类型
member：基类Base在派生类Derived中定义的名字
void *__mptr = (void *)(ptr);
这一条使用一个临时变量__mptr赋值，仅仅是为了避免对ptr的误操作导致修改了ptr的值，这可不是我们的初衷。思考一下，为什么在这里要使用void类型，保持原类型可不可以？
BUILD_BUG_ON_MSG(...);
这一条包含两个操作，首先是使用__same_type宏，其实这个宏名就已经解释了这个宏的作用，即判断传入的两个类型是否一致：
# define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b))
__builtin_types_compatible_p是一个內建功能函数，typeof是gcc关键字，这里的作用是判断传入的两个参数类型是否匹配。
然后是BUILD_BUG_ON_MSG宏：
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
这个宏检测cond(condition)，如果条件不为零，输出msg。
这一部分总体的作用就是检测container_of(ptr, type, member)中，ptr的类型是否和member类型一致，如果不一致，则报错。
((type *)(__mptr - offsetof(type, member)))
这一部分就是核心所在。
首先，使用offsetof找到基类Base在派生类中的偏移地址，原型是这样的：
#define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER)
&((TYPE *)0)->MEMBER：这一个表达式将0地址强制转换成TYPE类型(TYPE是用户传入的派生类Derived的类型)，然后访问member成员，用&获取member成员地址。对C语言不那么熟悉的小伙伴会非常疑惑：
-
不是说0地址是非法地址么，为什么这里可以用？0地址是非法地址没错，但是仅仅是限于不能进行访问操作。
-
为什么经过强制转换的0地址可以访问member成员，显然0地址处并不存在TYPE的实例？这个问题其实就是属于指针以及指针类型的经典难题了，这里简要解释一下：
首先我们要弄清楚指针的类型以及指针指向数据的类型。
指针是变量，指针的值为一个地址，指针本身的类型是int型，而指针指向数据的类型则有多种，常见的int，char等等
当我们对一个指针变量进行加减运算时，事实上是以指针指向数据类型的size进行操作，
比如ptr指向一个int类型，ptr值为0x1000，ptr++是将指针的值+4(32位)，即0x1004,若是指向char型，ptr++就是+1,ptr值为0x1001
而我们对目标类型进行强制转换，比如ptr本来是指向int型，我们这样操作：((char)prt)++,这样ptr就临时成为了char型指针，ptr++的操作时ptr的值只+1，即0x1001.
即强制转换提供一种临时的类型变换，在强制转换过程中目标地址保持为被转换类型。
对于结构体而言，结构体指针可以直接通过->来访问某个成员。
而我们对0地址进行强制转换，就可以看成是0地址处放置了一个目标结构体的实例，然后通过->成员来访问，当然这里并没有访问，如果访问肯定会出错，这里只是取出了member的相对于结构体地址的偏移地址。
刚刚只是介绍了offsetof(type, member)，然后我们结合来看((type *)(__mptr - offsetof(type, member)))：
__mptr-offsetof(type, member)：即基类ptr在结构体中的地址减去基类ptr在结构体中的偏移地址，就得到了派生类结构体的地址(这一部分涉及到结构体的存储方式)。
刚刚我们提到了一个问：为什么在__mptr要使用void类型，保持原类型可不可以？如果你理解了我上面提到的指针部分，这个问题就很好解释了：
如果__mptr为void类型，__mptr - offsetof(type, member)这个表达式就是__mptr的值减去offsetof(type, member)的值，得到__mptr。
如果保持原类型，__mptr - offsetof(type, member)这个表达式成了__mptr的值减去 offsetof(type, member)sizeof(type),得到__mptr,显然，我们要的是第一种。
（参考上面的指针类型简析的第四行）
小结
container_of(ptr, type, member)。
ptr为基类在结构体中的地址，
type为派生类类型，
member为基类在派生类中定义时的名字，其实就是为了在宏中直接以member名来访问。
总的来说，就是我们可以通过结构体内元素指针的值获取结构体的值。其实container_of的用法并不局限于kobject系统中，而是适用于所有基类派生类的模式。
示例
上面讲了那么多概念，还是得用实例来说话，下面是博主写的一个小demo：
1 #include <stdio.h>
2
3 struct Base{ //定义一个Base类
4 int var;
5 char *string;
6 };
7
8 struct Derived{ //定义一个派生类
9 int var;
10 struct Base base; //派生类中包含了struct Base类
11 };
12 #define offsetof(TYPE, MEMBER) ((size_t)&((TYPE *)0)->MEMBER) //offset_of宏
13 #define container_of(ptr, type, member) ({ \ //阉割版container_of，省去了类型检查
14 void *__mptr = (void *)(ptr); \
15 ((type *)(__mptr - offsetof(type, member))); })
16
17 struct Base *base_p;
18 struct Derived test_derived;
19
20
21 struct Derived *get;
22 int main()
23 {
24 base_p = &test_derived.base; //赋值给指针
25 printf("Derived addr = %x\n",(unsigned int)&test_derived);
26 printf("=================================\n");
27 get = container_of(base_p,struct Derived,base); //使用base_p指针获取派生类的首地址
28 printf("get Derived addr = %x\n",(unsigned int)get);
29
30 return 0;
31 }
输出：
Derived addr = 601050
=================================
get Derived addr = 601050
你是否真的懂了？
为了考验你是否真的懂了，博主准备了一个问题，欢迎留言：
第10行的定义中能否换成指针类型？如果换成指针类型，container_of()还能否实现，为什么？
博主非常建议你动手试试！！！
好了，关于linux驱动中container_of()宏的讨论就到此为止啦，如果朋友们对于这个有什么疑问或者发现有文章中有什么错误，欢迎留言
原创博客，转载请注明出处！
祝各位早日实现项目丛中过，bug不沾身.
