摘要
接下来,才是某个特定的设备的驱动的框架
想要实现某个特定的设备的驱动之前,就先要对该设备,在Linux的整体的驱动体系中,处于什么部分,属于什么驱动方面的子框架,要有所了解。
而这些子驱动框架,则是针对一类设备,统一管理,实现了该类设备的通用的功能和逻辑
这样作为驱动开发人员,可以免去这部分的开发的工作,省了很多心
比如:
就是针对,内存类存储设备,而设计的一套框架,而属于内存类设备的,比如Nand Flash,Nor Flash等等,在编写驱动时,就要知道自己所要写的设备的驱动,是从属与MTD框架的
要知道,MTD框架,已经为我们所实现了哪些功能
比如MTD中的drivers/mtd/nand/nand_base.c
中已经帮我们实现了,作为通用的MTD设备中的Nand Flash都会用到的:
nand_command
,nand_command_lp
nand_read_buf
,nand_write_buf
nand_read_page_swecc
,nand_read_page_hwecc
, nand_write_page_raw
, nand_write_page_hwecc
nand_read_oob_std
,nand_write_oob_std
nand_block_isbad
,nand_block_markbad
,nand_block_isreserved
如此众多的功能和函数,都是Linux的MTD框架都是帮你写好了的。
换句话说,如果没有Linux的MTD框架,让你从头到尾,一点点写出一个完整的Linux的Nand Flash的驱动的话,对于上述提到的各种针对oob,page,block,command等等的操作,都是需要你自己从无到有去实现出来的。
Linux中的USB子驱动框架,也是帮我们实现了太多的基础的通用的功能。包括class,interface,endpoint,等等方面的基本功能,比如:
drivers/usb/common/common.c
speed_names
usb_device_state
usb_dr_modes
drivers/usb/core/devices.c
clas_info
usb_device_read
usb_dump_device_descriptor
,usb_dump_hub_descriptor
,usb_dump_config_descriptor
,usb_dump_interface_descriptor
比如,最常见的USB大容量存储设备,即常说的U盘:
drivers/usb/storage/protocol.c
usb_stor_ufi_command
usb_stor_transparent_scsi_command
上述列出了很多不同模块和领域的驱动相关的名称,概念,咋一看会显得难以理解,但是实际上不用太关心此处的细节,而只需要记住一点即可:
Linux的驱动,对于在某个子领域内,已经帮我们设计好了,适用于该领域的通用的框架,对应着某个驱动的子框架,且已经帮我们实现好了,大量的,常见和通用的功能
这样我们在实现对应设备驱动的时候,对于该设备所属的领域内的通用的功能,就可以不用自己再重新写了,就避免了重复造轮子的无用功的浪费了。
由此可见:在Linux下面写某设备的驱动,虽然需要增加额外的精力去学习该设备所属的驱动的子框架,但是这点额外的学习成本,和该框架帮你省下的精力相对,要划算的多。
即:Linux子驱动框架已经帮我们实现了非常多通用的功能部分,可以帮我们写驱动时,省掉很大一部分精力,而我们只需要搞懂子驱动框架后,去实现余下的和设备相关的部分即可。