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