关于驱动框架的回顾

今天正好赶上要放五一长假了，正好把自己在这段时间看的关于驱动方面的知识做一个回顾。

驱动是操作系统的一部分，linux操作系统内核中的85%左右都是关于驱动的代码，之前也断断续续看过一段时间的驱动源码，但是都是匆匆看过，大致熟悉了以下，对其中的脉络其实掌握的不是十分清楚，这一次重新看了字符设备驱动程序，和linux内核中的异常向量（主要是中断部分），颇有感触，感觉想写一些东西梳理一下，因此在今天抽空做个总结吧。

首先字符设备驱动程序大致可以分为这几个部分，app：read、write、open；系统调用；下面是内核部分：响应应用程序的异常向量处理；驱动程序：.read、.write、.open；再往下就是硬件相关的程序。

基本的字符设备驱动程序大致就是上述的几个部分，但是到底程序是怎样的运行的。

例子：

1. 在应用程序中想要read一个设备文件.
2. app中的read函数完成系统调用，这是arm处理器会已swi响应app，跳转到内核中的响应应用程序的异常向量，之后找到相应的驱动程序，返回一个文件句柄，将文件句柄返回给系统调用，最后返回给应用程序。
3. 这是应用程序会发出相应的控制命令，发给系统调用之后，通过swi响应应用程序的异常向量，然后调用响应的驱动函数即.read函数，完成响应的读功能。

基本字符设备驱动程序的基本框架就是这样的，是以字节的方式来进行传输的。

linux内核中的异常向量，说句实话，真鸡儿复杂，看的头大，但是不得不佩服，针对arm芯片来说的话，linux的异常向量的个数和arm芯片的型号也是有关系的，以S3C2440为例的话，因为其有7中工作模式，系统（用户）模式，中断模式、快速中断模式、未定义指令模式、数据访问中止模式、管理模式，那么自然的其内核设置也同样会设置这些跳转向量，每个向量都对应的有响应的处理函数。所谓的中断呢，就是指这里的中断模式，然后在这个中断模式中有32个中断，当然每个中断都可以是一组，或者是一个。

未完待续