经典摘录

come from : https://blog.51cto.com/21cnbao/1946351

谈Linux的总线、设备、驱动模型

软件工程强调高内聚、低耦合。若一个模块内各元素联系的越紧密，则它的内聚性就越高；模块之间联系越不紧密，其耦合性就越低。所以高内聚、低耦合强调，内部的要紧紧抱团，外面的给我滚蛋。

基于这样的想法，linux把设备驱动分为了总线、设备和驱动三个实体，总线是上图中的统一纽带，设备是上图中的板级互连信息，这三个实体完成的职责分别如下:

实体	功能	代码
设备	描述基地址、中断号、时钟、DMA、复位等信息	arch/arm arch/blackfin arch/xxx 等目录
驱动	完成外设的功能，如网卡收发包，声卡录放，SD卡读写…	drivers/net sound drivers/mmc 等目录
总线	完成设备和驱动的关联	drivers/base/platform.c drivers/pci/pci-driver.c …

这样platform的总线这个统一纽带上，自然就知道板子上面有2个DM9000的网卡。一旦DM9000的驱动也被注册，由于platform总线已经关联了设备，驱动自然可以根据已经存在的DM9000设备信息，获知如下的内存基地址、中断等信息了：

总线存在的目的，则是把这些驱动和这些设备，一一配对的匹配在一起。

这样，板级互连信息，再也不会闯入驱动，而驱动，看起来也没有和设备之间直接耦合，因为它调用的都是总线级别的标准API：platform_get_resource()。总线里面有个match()函数，来完成哪个设备由哪个驱动来服务的职责，比如对于挂在内存上的platform总线而言，它的匹配类似（最简单的匹配方法就是设备和驱动的name字段一样）：

我们有理由，把这些设备端的信息，用一个非C的脚本语言来描述，这个脚本文件，就是传说中的Device Tree（设备树）。

设备树，是一种dts文件，它用最简单的语法描述每个板子上的所有设备，以及这些设备的连接信息。

换个板子，只要换个Device Tree就好。“让天堂的归天堂， 让尘土的归尘土”，让驱动的归驱动C代码，让设备的归设备树脚本。

Linux设备驱动的分层设计思想

1.1 设备驱动核心层和例化

在面向对象的程序设计中，可以为某一类相似的事物定义一个基类，而具体的事物可以继承这个基类中的函数。如果对于继承的这个事物而言，其某函数的实 现与基类一致，那它就可以直接继承基类的函数；相反，它可以重载之。这种面向对象的设计思想极大地提高了代码的可重用能力，是对现实世界事物间关系的一种 良好呈现。

Linux内核完全由C语言和汇编语言写成，但是却频繁用到了面向对象的设计思想。在设备驱动方面，往往为同类的设备设计了一个框架，而框架中的核 心层则实现了该设备通用的一些功能。同样的，如果具体的设备不想使用核心层的函数，它可以重载之。

return_type core_funca(xxx_device * bottom_dev, param1_type param1, param1_type param2)
{
if (bottom_dev->funca)
return bottom_dev->funca(param1, param2);
/* 核心层通用的funca代码 */
...
}
上述core_funca的实现中，会检查底层设备是否重载了funca()，
如果重载了，就调用底层的代码，否则，直接使用通用层的。
这样做的好 处是，核心层的代码可以处理绝大多数该类设备的funca()对应的功能，只有少数特殊设备需要重新实现funca()。

那么，我们可以用如图12.4的思想对主机控制器驱动和外设驱动进行分离。这样的结构是，外设a、b、c的驱动与主机控制器A、B、C的驱动不相关，主机控制器驱动不关心外设，而外设驱动也不关心主机，外设只是访问核心层的通用的API进行数据传输，主机和外设之间可以进行任意的组合。