一、设备驱动的作用？
任何一个计算机系统的运行都是系统中软硬件协作的结果，没有硬件的软件是空中楼阁，而没有软件的硬件则只是一堆废铁。 硬件是底层基础，是所有软件得以运行的平台，代码最终会落实为硬件上的组合逻辑与时序逻辑；软件则实现了具体应用，它按照各种不同的业务需求而设计，满足了用户的需求。硬件较固定，软件则很灵活，可以适应各种复杂多变的应用。可以说，计算机系统的软硬件互相成就了对方。
但是，软硬件之间同样存在着悖论，那就是软件和硬件不应该互相渗透到对方的领地。为了尽可能快速地完成设计，应用软件工程师不想也不必关心硬件，而硬件工程师也难有足够的闲暇和能力来顾及软件。例如，应用软件工程师在调用套接字发送和接收数据包的时候，他不必关心网卡上的中断、寄存器、存储空间、I/O端口、片选以及其他任何硬件词汇；在使用printf()函数输出信息的时候，他不用知道底层究竟是怎样把相应的信息输出到屏幕或串口。
也就是说，应用软件工程师需要看到一个没有硬件的纯粹的软件世界，硬件必须被透明地呈现给他们。谁来实现硬件对应用软件工程师的隐形？这个艰巨的任务就落在了驱动工程师的头上。
对设备驱动最通俗的解释就是“驱使硬件设备行动”。设备驱动与底层硬件直接打交道，按照硬件设备的具体工作方式读写设备寄存器，完成设备的轮询、中断处理、DMA通信，进行物理内存向虚拟内存的映射，最终使通信设备能够收发数据，使显示设备能够显示文字和画面，使存储设备能够记录文件和数据。
由此可见，设备驱动充当了硬件和应用软件之间的纽带，它使得应用软件只需要调用系统软件的应用编程接口（API）就可让硬件去完成要求的工作。在系统中没有操作系统的情况下，工程师可以根据硬件设备的特点自行定义接口，如对串口定义SerialSend()、SerialRecv()；对 LED 定义LightOn()、LightOff()；以及对 Flash 定义FlashWrite()、FlashRead()等。而在有操作系统的情况下，设备驱动的架构则由相应的操作系统定义，驱动工程师必须按照相应的架构设计设备驱动，这样，设备驱动才能良好地整合到操作系统的内核中。
驱动程序沟通着硬件和应用软件，而驱动工程师则沟通着硬件工程师和应用软件工程师。随着通信、电子行业的迅速发展，全世界每天都会有大量的新芯片被生产，大量的新电路板被设计，因此，也会有大量设备驱动需要开发。这些设备驱动，或运行在简单的单任务环境中，或运行在 VxWorks、Linux、 Windows等多任务操作系统环境中，发挥着不可替代的作用。
二、裸机设备驱动和linux系统中的设备驱动有什么区别？
1、裸机(无操作系统)设备驱动
并不是任何一个计算机系统都一定要运行操作系统，在许多情况下操作系统是不要的。对于功能比较单一、控制并不复杂的系统，如公交车刷卡机、电冰箱、微波、简单的手机和小灵通等，并不需要多任务调度、文件系统、内存管理等复杂功能，单任务架构完全可以很好地支持它们的工作。一个无限循环中夹杂对设备中断的检测或者对设备的轮询是这种系统中软件的典型架构。裸机的实现就有点类似单片机（MCU），尽管单片机的寄存器没有那么的多。
在这样的系统中，虽然不存在操作系统，但是设备驱动是必须存在的。一般情况下，对每一种设备驱动都会定义为一个软件模块，包含.h文件和.c文件，前者定义该设备驱动的数据结构并声明外部函数，后者进行设备驱动的具体实现。比如一个串口驱动，主要是配置GPIO，串口控制寄存器，以及串口的收发（读写）寄存器，而这几个配置都是自定义函数实现的，比如串口的写（发）SerialSend函数等。
其他模块需要使用这个设备的时候，只需要包含设备驱动的头文件 serial.h，然后调用其中的外部接口函数即可。如我们要从串口上发送字符串“Hello World”，使用函数SerialSend( " Hello World ")即可。
由此可见，在没有操作系统的情况下，设备驱动的接口被直接提交给了应用软件工程师， 应用软件没有跨越任何层次就直接访问了设备驱动的接口。 设备驱动包含的接口函数也与硬件的功能直接吻合， 没有任何附加功能。
有的工程师把单任务系统设计成设备驱动和具体的应用软件模块处于同一层次（即应用程序也在比如serial.c中实现），这显然是不合理的，不符合软件设计中高内聚低耦合的要求。另一种不合理的设计是直接在应用程序中操作硬件的寄存器（单独一个main.c，所有功能都在这一个函数中实现，不采用其他任何接口/函数），而不单独设计驱动模块，这种设计意味着系统中不存在或未能充分利用可被重用的驱动代码。
2、Linux系统(有操作系统)中的设备驱动
无操作系统时的设备驱动中的设备驱动直接运行在硬件之上，不与任何操作系统关联。当系统中包含操作系统后，设备驱动会变得怎样？
首先，有操作系统时设备驱动的硬件操作工作仍然是必不可少的， 没有这一部分，我们不可能与硬件打交道。其次，我们还需要将设备驱动融入内核。为了实现这种融合，必须在所有的设备驱动中设计面向操作系统内核的接口，这样的接口由操作系统规定，对一类设备而言结构一致，独立于具体的设备。
由此可见，当系统中存在操作系统的时候，设备驱动变成了连接硬件和内核的桥梁。操作系统的存在势必要求设备驱动附加更多的代码和功能（以我看，主要是提供了很多结构），把单一的“驱使硬件设备行动”变成了操作系统内核与硬件交互的模块，它对外呈现为操作系统的API(这里的操作系统可以理解为内核，内核可以被应用程序通过系统调用来访问)，不再给应用软件工程师直接提供接口(但是在裸机中，驱动程序的接口是直接提供给应用程序的)。因为应用程序在用户空间，驱动程序在内核空间，所以就必须先由应用程序进行系统调用进入内核，然后再调用驱动程序中和该系统调用相对应的API。
下面以字符设备驱动为例，看下面的几张流程图，或许你就能明白上述所说是什么意思：
- 应用程序对驱动程序的系统调用，可能经过C库，也可能不使用C库
- 以字符设备驱动程序中的open函数为例，来看一下其函数调用流程
其中关于 C 库以及如何通过系统调用“陷入”到内核空间这个我们不用去管，我们重点关注的是应用程序和具体的驱动，应用程序使用到的函数在具体驱动程序中都有与之对应的函数，比如应用程序中调用了open这个函数，那么在驱动程序中必定有一个和open函数对应的一个函数，这个函数名我们是可以自定义的，比如char_open。每一个系统调用，在驱动中都有与之对应的一个驱动函数，在 Linux 内核文件 include/linux/fs.h中有个叫做 file_operations的结构体，此结构体就是 Linux 内核驱动操作函数集合，内容如下所示：
1588 struct file_operations {
1589 struct module *owner;
1590 loff_t (*llseek) (struct file *, loff_t, int);
1591 ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
1592 ssize_t (*write) (struct file *, const char __user *, size_t,loff_t *);
1593 ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
1594 ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
1595 int (*iterate) (struct file *, struct dir_context *);
1596 unsigned int (*poll) (struct file *, struct poll_table_struct *);
1597 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
1598 long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
1599 int (*mmap) (struct file *, struct vm_area_struct *);
1600 int (*mremap)(struct file *, struct vm_area_struct *);
1601 int (*open) (struct inode *, struct file *);
1602 int (*flush) (struct file *, fl_owner_t id);
1603 int (*release) (struct inode *, struct file *);
1604 int (*fsync) (struct file *, loff_t, loff_t, int datasync);
1605 int (*aio_fsync) (struct kiocb *, int datasync);
1606 int (*fasync) (int, struct file *, int);
1607 int (*lock) (struct file *, int, struct file_lock *);
1608 ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
1609 unsigned long (*get_unmapped_area)(struct file *,
unsigned long,unsigned long,
unsigned long, unsigned long);
1610 int (*check_flags)(int);
1611 int (*flock) (struct file *, int, struct file_lock *);
1612 ssize_t (*splice_write)(struct pipe_inode_info *, struct file *,
loff_t *, size_t, unsigned int);
1613 ssize_t (*splice_read)(struct file *, loff_t *,
struct pipe_inode_info *,
size_t, unsigned int);
1614 int (*setlease)(struct file *, long, struct file_lock **, void **);
1615 long (*fallocate)(struct file *file, int mode, loff_t offset,loff_t len);
1616 void (*show_fdinfo)(struct seq_file *m, struct file *f);
1617 #ifndef CONFIG_MMU
1618 unsigned (*mmap_capabilities)(struct file *);
1619 #endif
1620 };
简单介绍一下 file_operation 结构体中比较重要的、常用的函数：
- 第 1589 行，
owner拥有该结构体的模块的指针，一般设置为THIS_MODULE。 - 第 1590 行，
llseek函数用于修改文件当前的读写位置。 - 第 1591 行，
read函数用于读取设备文件。 - 第 1592 行，
write函数用于向设备文件写入(发送)数据。 - 第 1596 行，
poll是个轮询函数，用于查询设备是否可以进行非阻塞的读写。 - 第 1597 行，
unlocked_ioctl函数提供对于设备的控制功能，与应用程序中的 ioctl 函数对应。 - 第 1598 行，
compat_ioctl函数与unlocked_ioctl函数功能一样，区别在于在 64 位系统上，32 位的应用程序调用将会使用此函数。在 32 位的系统上运行 32 位的应用程序调用的是unlocked_ioctl。 - 第 1599 行，
mmap函数用于将设备的内存映射到进程空间中(也就是用户空间)，一般帧
缓冲设备会使用此函数，比如 LCD 驱动的显存，将帧缓冲(LCD 显存)映射到用户空间中以后应用程序就可以直接操作显存了，这样就不用在用户空间和内核空间之间来回复制。 - 第 1601 行，
open函数用于打开设备文件。 - 第 1603 行，
release函数用于释放(关闭)设备文件，与应用程序中的close函数对应。 - 第 1604 行，
fasync函数用于刷新待处理的数据，用于将缓冲区中的数据刷新到磁盘中。 - 第 1605 行，
aio_fsync函数与fasync函数的功能类似，只是aio_fsync是异步刷新待处理的数据。
在字符设备驱动开发中最常用的就是上面这些函数，关于其他的函数大家可以查阅相关文档。我们在字符设备驱动开发中最主要的工作就是实现上面这些函数，不一定全部都要实现，但是像 open、release、write、read等都是需要实现的，当然了，具体需要实现哪些函数还是要看具体的驱动要求。
最后，需要强调的一点是，这里只是以字符设备驱动为例来讲解应用程序是怎么访问到设备驱动程序的，以上所说的结构体以及其中定义的函数都是针对的字符设备驱动，而且它也不限于这些函数，肯定还有很多其他的函数需要实现。我们知道设备驱动分为三大类，分别是字符设备，块设备和网络设备，因为不同的设备驱动类别都有对应的各自不同的框架，也即不同的结构体和函数等一些东西，因此我们需要实现的是该类别设备驱动对应的函数。至于这三种类别的设备驱动程的框架以及程序如何编写，等到后面到这一部分的时候再总结。
有了操作系统之后，设备驱动反而变得复杂，那要操作系统干什么？首先，一个复杂的软件系统需要处理多个并发的任务，没有操作系统，想完成多任务并发是很困难的。其次，操作系统给我们提供内存管理机制。一个典型的例子是，对于多数含 MMU的处理器而言，Windows、Linux等操作系统可以让每个进程都独立地访问 4GB的内存空间。
上述优点似乎并没有体现在设备驱动身上，操作系统的存在给设备驱动究竟带来了什么好处呢？简而言之，操作系统通过给设备驱动制造麻烦来达到给上层应用提供便利的目的。如果设备驱动都按照操作系统给出的独立于设备的接口而设计，应用程序将可使用统一的系统调用接口来访问各种设备。对于类UNIX的VxWorks、Linux等操作系统而言，应用程序通过write()、read()等函数读写文件就可以访问各种字符设备和块设备，而不用管设备的具体类型和工作方式，是非常方便的。
参考文章：
https://blog.csdn.net/ChenGuiGan/article/details/84305576
本人小白，是从零开始学习linux驱动开发的，这是自己在学习过程中写的博客，所以肯定会有不正确的地方，如果有还请各位指出来！！！