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进行数据传输,主机和外设之间可以进行任意的组合。