1.字符设备驱动程序概念介绍-蒲公英云

1.字符设备驱动程序概念介绍

u-boot的任务是启动内核，内核的任务是启动应用程序。应用程序会涉及很多文件和硬件操作（当然不会直接操作硬件），比如读写文件，点灯、获取按键值。

对于应用程序的开发人员不要求去阅读芯片手册，了解硬件的构造。应用程序的开发人员在用户空间直接使用open、read、 write等等这些被称为系统调用的函数，通过这些函数进入内核空间，进而调用内核空间的驱动程序。

比如对于控制led灯的用户程序与驱动程序，最简单的实现方法是，应用程序中需要打开led灯，就需要open函数,在内核中的驱动程序中也有对应的led_open函数，这个led_open函数负责直接操作硬件，应用程序中要调用read函数读取led灯的状态的时候，内核中的驱动程序也有led_read函数。这是应用程序与内核中驱动程序一种最简单的对应方式。

那么应用程序中的open、read函数最终怎样调用到驱动程序中的led_open、led_read呢，中间有哪些东西。

我们首先写一个简单的应用程序。

int main()

{

      int fd1; fd2;
      int val = 1;
      fd1 = open("/dev/led", O\_RDWR);
      write(fd1, &val, 4);
      fd2 = open("/home/xxx/hello.txt", O\_RDWR);
      write(fd2, &val, 4);

}

这些open、write函数在Linux中称为系统调用，是用户态进入内核态的门户。当处于用户空间的应用程序调用这些系统调用的时候，会进入内核空间执行。这些系统调用怎样进入内核态呢？这些系统调用会调用一条汇编指令：swi 。在swi指令后面会跟着一个值。这个值用来表明是哪一条系统调用调用了该swi汇编指令，也就是说不同的系统调用调用swi指令，swi后面跟着的值都是不同的。这条汇编指令会引发一个叫做内核陷入的异常。引发内核异常会进入到一个内核异常处理函数中。内核异常处理函数会根据异常发生的原因，调用不同的处理函数。异常发生的原因是根据swi后面跟着的值来决定的，比如说open函数执行swi，swi后面跟着的值是val1,read函数执行swi，swi后面跟着的值是val2。内核中一个称为虚拟文件系统的东西会根据swi后面不同的值去调用system_open或者system_read等

函数。

再看上面的应用程序，我们点灯与打开文本文件，都是用的同样的函数。但是点灯与打开文本文件的行为显然不一样。那么谁来实现

这些不一样的行为呢？

对于LED灯，有led_open驱动程序。对于文本文件存在于flash设备上，也有对于的驱动程序。system_open、system_read最终会根据打开的不同文件，找到底层的不同驱动程序的，然后调用驱动程序中的硬件操作函数比如led_open来实现对具体硬件设备的操作。