linux驱动分离思想引入——总线模型（上）

对于驱动的分离思想其实我们很早就有接触了，只是当时我们在单片机阶段并没有深刻去理解它的做法而已。以前我们在学单片机的时候以点灯驱动代码为例如下图所示：

我们裸机普遍的操作就是查看原理图，确认引脚连接关系，然后编写驱动，但是我们发现，不管是电灯、还是让蜂鸣器响，其本质操作都是操作GPIO的DIR寄存器控制IO方向，操作Data寄存器设置输出高低电平或者读取引脚电平，而且这些操作对于大多数引脚几乎都是一样的，也就引脚名称不一样（这也是我们在开发中懒得编写在网上直接复制粘贴修改的原因哈哈哈）。同样也是为什么引出库函数的原因。

上图以HAL库为例，比如设置引脚输出电平的这些重复性的工作，对于不同的IO引脚的设置只有引脚不同，其寄存器操作是一样的，那么我们在实际电灯的时候，在led_driv驱动里面只需要确定引脚资源便可以实现该寄存器的操作，同样蜂鸣器的操作也是一样的，只是引脚上的差异。很明显这个函数的代码不用更改，只需要我们在调用的时候传入不同引脚即可，该函数高大尚的名字也称它为驱动（driver）。

那么什么是分离思想呢？还是以点灯代码为例，我们虽然可以调用上图的HAL库函数在led_driv或者beep_driv中实现灯、蜂鸣器的控制，但是我们如果直接复制点灯的代码总归是要修改源代码很多东西，比如初始化GPIO的引脚名称要改，函数名称要改（如果你觉得也没多少呀，就当我没说过吧（当你有几十上百个IO要改的时候就觉得我说的有道理了）），改完之后重新编译烧写。基于这个问题，我们能不能将驱动分离为两个.c文件，将要改动大的放在一个文件（代码跟硬件资源紧密相关），改动少的放在一个文件呢（代码跟硬件资源没有什么关系）？在linux驱动就引入了这种机制，就是驱动、总线、设备模型如下图所示。

想想要实现分离，肯定不是简单的将驱动写在两个文件即可。思考一下我们至少需要要解决的问题：1、这两个文件怎么关联起来？；2、如何管理众多的driver、device？；3、不同的driver如何能准确找到device？

答1：在linux里面抽象出一个总线(bus)结构体来管理设备和驱动；

答2：通过链表的方式管理drvier、device；

答3：通过在注册时驱动和设备约好的暗号（其实就是注册时的名字），这样通过遍历链表匹配就可以了。

最后总结一下分离的思想：

至此分离思想就先讲到这里，更精彩的linux中platform模型请关注笔者，下篇继续深入揭晓platform模型。