c风格的面向对象--linux内核学习

Linux使用了struct这个来实现对象,函数指针来实现方法。比如说，设备是一个类，每一个驱动程序都将这个类实例化，然后交给内核。

linux内核大量地使用了oo的思想，只是没有用C++罢了。凡是那些结构体里有函数指针表的基本都借鉴了oo的思想，而这些函数的参数中又有一个参数是指向这个结构体的指针，相当于this指针。

linux内核大量使用面向对象的编码风格。然而linux内核是完全使用C写就。学习他们如何使用C模拟面向对象机制很有意思。这种做法很可能被人贬为扯淡，但是的确使用C模拟面向对象机制，使得程序员对类型构造/析构，拷贝/赋值等操作有了绝对的控制权，可以提高对效率的嗅觉，减少错误，同时也避免了对C++编译器各种不同类/对象实现机制的依赖。

类的多态特征是linux内核经常用到的。例如在驱动代码中常常使用函数指针来定义一组设备操作函数，从而模拟了多态的特点。

struct file_operations scull_fops  ={  .owner = THIS_MODULE,  .llseek = scull_llseek,  .read = scull_read,  .write = scull_write,  .ioctl = scull_ioctl,  .open = scull_open,  .release = scull_release,};

上面的例子是Linux Device Driver中抄来的示例代码。很好地展示了file operation结构体如何使用这种机制来定义一组文件操作的方式。用这种方式，Linux很好地贯彻了所有的设备都是文件这种概念。不同的设备可以有不同的处理函数，但使用相同的接口(read,write...)，这样就把底层设备的差异在文件系统这一层隔离开来了。

Linux内核中也经常用到类的继承关系。这种关系使用C也很容易模拟，就是使用结构体嵌套。例如

struct scull_dev {struct scull_qset *data;int quantum;int qset;unsigned long size;unsigned int access_key;struct semaphore sem;struct cdev cdev;      //内嵌linux内核定义的cdev结构体};

这个例子同样来自LDD。注意在自定义的cdev字符设备结构体中包含了struct cdev cdev成员。这个成员同样是一个结构体，由内核定义，是字符设备描述符。使用这种方式，可以一定程度模拟C++的继承机制，当然有他的局限，例如他不能如同在C++中一样直接引用cdev的成员，而必须通过scull_dev.cdev来引用。

另一方面，这种方式也无法通过“基类”，即cdev的指针，访问“子类”，即scull_dev的成员。精彩的部分来了，linux通过一组宏，巧妙的实现了这一点。在文件处理的函数中，入参会给入inode指针，从这个指针可获得其cdev成员。如何从这个cdev成员获取包含它的“子类”对象，scull_dev的指针呢？

container_of(ptr, type, member)

使用这个宏，container_of(inode->i_cdev, struct scull_dev, cdev)就可获得包含cdev的scull_dev的地址。这个巧妙的宏是如何实现的呢？

#define container_of(ptr, type, member) ({ const typeof( ((type *)0)->member ) *__mptr = (ptr);(type *)( (char *)__mptr - offsetof(type,member) );})

这个宏首先定义一个指向结构体成员的指针__mptr = (ptr)，他的类型是const typeof(...)。这里用到了C语言一个较新的关键字typeof，可以在编译期获得变量的类型。而这个类型是((type*)0)->member，这里type和member分别是宏传入的参数。这一行代码就比较清晰了。得到这个__mptr之后，将他向回移动一个offset，(char*)__mprt - offsetof(...)，而这个offset恰好为member相对于type的偏移量，offsetof(type,member)，则移动完毕__mptr就指向type类型的起始地址了，只需将其转换为type*类型就可以了，(type*)(...)。

好了，这个宏已经看懂，神奇的地方就出在这个offsetof宏了，他是如何计算成员相对于结构体的偏移量呢？这里linux内核hacker们用了一个小小trick。

#define offsetof(s, m)   (size_t)&(((s *)0)->m)

是的，代码非常简单。其思想是，假如结构体处于0地址，获取其成员的地址。这个地址就是成员相对于结构体初始地址的偏移量了。没错0地址是不能运行时访问的，但这句代码只在编译期使用了0地址，因此是合法的。当然其实使用成员指针和结构体指针相减也可做到，但用这种方式可以减少一次运算，确保了这个宏可以在编译期求出结果。可谓是精益求精。

我说错了。即使使用减法也可以做到编译期求值，因为结构体和成员指针地址都是可以编译期得到的，常量数值计算应该可以做到编译期优化，计算完成。这种做法应该是
&((type*)0)->member - ((type*)0)
这样的代码的一个直觉性的优化，减0的话，何必还要减呢。事实上两句代码的运行时间是一样的，但这样做可以减轻编译时间。
在container_of宏中，也有一句减法计算。这个计算引用了运行时求值的__mptr，所以无法做到编译期求值。

类似这种用法，在linux内核中经常出现。深深佩服大牛们的创造力，并且深深的意识到了即使是C语言也是学无止境的。

举例：面向对象的思想在linux设备模型中的应用分析.

通过设备模型，看到了面向对象编程思想用C语言的实现。内核中常见到封装了数据和方法的结构体，这是面向对象封装特性的实现。而这里展现的更多的是继承方面的实现。比如说pci_driver，它的父类是device_driver，而更上一层是一个kobject。在C++中，继承一个父类则子类中相应的包含父类的一个实例。内核中也是通过包含一个父类的实体来实现这种派生关系。因此，一个pci_driver内部必然包含一个device_driver,同样，device_driver内部必然包含一个kobject。
上面提到过，注册一个模型的过程类似于面向对象中构造函数的调用。子类需要调用父类构造函数来完成自身的构造。再来看看注册一个pci_driver的过程：
pci_register_driver(struct pci_driver *driver)
-->driver_register(&drv->driver);
-->kobject_register(&drv->kobj);
这不是OO中的继承么？

设备模型源码中还能找到多态(虚函数)的思想。看到pci_driver和device_driver中提供了差不多同名的方法不觉得奇怪吗？？它们不同的地方在于参数。pci_driver中方法的参数是pci_device * dev ,而device_driver方法的参数则是 device *dev 。这么安排是有意的!
最典型的例子莫过于platform_driver和device_driver。
struct platform_driver
 {
 int (*probe)(struct platform_device *);
int (*remove)(struct platform_device *);
void (*shutdown)(struct platform_device *);
int (*suspend)(struct platform_device *, pm_message_t state);
int (*resume)(struct platform_device *);
struct device_driver driver;
};
这显然比pci_driver来得简洁。platform_driver除了包含一个device_driver，其它就是5个与device_driver同名的方法。
注册一个platform_driver的过程：
int platform_driver_register(struct platform_driver *drv)
{
drv->driver.bus = &platform_bus_type;
if (drv->probe)
drv->driver.probe = platform_drv_probe;
if (drv->remove)
drv->driver.remove = platform_drv_remove;
if (drv->shutdown)
drv->driver.shutdown = platform_drv_shutdown;
if (drv->suspend)
drv->driver.suspend = platform_drv_suspend;
if (drv->resume)
drv->driver.resume = platform_drv_resume;
return driver_register(&drv->driver);
}

这里设置了platform_driver包含的device_driver的函数指针。看看这些函数中的platform_drv_probe。
static int platform_drv_probe(struct device *_dev)
{
struct platform_driver *drv = to_platform_driver(_dev->driver);
struct platform_device *dev = to_platform_device(_dev);

 return drv->probe(dev);
}

 

这里出现了两个指针类型转换(通过container_of()宏实现的)，然后调用platform_driver提供的probe函数。
考 虑一下platform_driver的注册过程。每个驱动注册过程相同。如前面分析过的，进入到driver_register后，设备驱动device_driver层的probe将会被调用来探测设备，这个函数像上面源码所指示的那样完成类型转化调用其子类platform_driver层的probe函数来完成具体的功能。那么，从device_driver层看来，相同的函数调用由子类来完成了不同的具体功能。这不是多态的思想么？？

这里非常粗浅的分析了linux设备模型中使用C实现面向对象的三大要素(封装，继承，多态)的基本思想。用C来实现确实做的工作要多一些，不过灵活性更高了。怪不得linus炮轰C++.
"使用优秀的、高效的、系统级的和可移植的C++的唯一方式，最终还是限于使用C本身具有的所有特性。"