Linux驱动开发面试题库
一、FIQ和IRQ区别
FIQ和IRQ是两种不同类型的中断，ARM为了支持这两种不同的中断，提供了对应的叫做FIQ和IRQ处理器模式（ARM有7种处理模式）。
一般的中断控制器里我们可以配置与控制器相连的某个中断输入是FIQ还是IRQ,所以一个中断是可以指定为FIQ或者IRQ的，为了合理，要求系统更快响应，自身处理所耗时间也很短的中断设置为FIQ，否则就设置了IRQ。
如果该中断设置为了IRQ，那么当该中断产生的时候，中断处理器通过IRQ请求线告诉ARM，ARM就知道有个IRQ中断来了，然后ARM切换到IRQ模式运行。类似的如果该中断设置为FIQ，那么当该中断产生的时候，中断处理器通过FIQ请求线告诉ARM，ARM就知道有个FIQ中断来了，然后切换到FIQ模式运行。
简单的对比的话就是FIQ比IRQ快，为什么快呢？
ARM的FIQ模式提供了更多的banked备份寄存器，r8 ～r14,SPSR；而IRQ模式提供的banked寄存器为R13,R14,SPSR，这就意味着在ARM的IRQ模式下，中断处理程序自己要保存R8到R12这几个寄存器，然后退出中断处理时程序要恢复这几个寄存器，而FIQ模式由于这几个寄存器都有banked寄存器，模式切换时CPU自动保存这些值到banked寄存器，退出FIQ模式时自动恢复，所以这个过程FIQ比IRQ快.
FIQ比IRQ有更高优先级，FIQ优先级为3，IRQ优先级为4。如果FIQ和IRQ同时产生，那么FIQ先处理；如果。
另外FIQ的入口地址是0x1c,IRQ的入口地址是0x18。
二、linux内核里申请内存的函数
kmalloc()、kzalloc()、vmalloc() 的共同特点是：
kmalloc()、kzalloc()、vmalloc() 的区别是：
https://blog.csdn.net/lu_embedded/article/details/51588902
三、中断处理分为上半部和下半部
中断处理的上半部和下半部都是不允许出现睡眠和阻塞的。但是对于下半部，并不是一刀切，不同下半部的实现方式有的不允许睡眠和阻塞（软中断和tasklet），有的是可以的（工作队列）
上半部：一般中断的中断处理函数为上半部，需要立即执行且耗时少的操作（时间太长，且如果该中断的标志是IRQF_DISABLED的话，会禁掉所有本地中断，这个函数时间长的话会对系统的性能早成严重影响）
下半部：由于上半部只能执行耗时少的操作，所以耗时长的操作就放在下半部，两个的界限并不是很明显，取决于我们要将哪个操作放在上半部还是下半部
##上半部：
中断的上半部是中断处理函数，要求做耗时少的动作，尽量迅速，一定不能休眠和阻塞
##下半部：
参阅《linux内核设计与实现》
四、
mmap基础概念
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。如下图所示：
mmap内存映射原理
mmap内存映射的实现过程，总的来说可以分为三个阶段：
（一）进程启动映射过程，并在虚拟地址空间中为映射创建虚拟映射区域
1、进程在用户空间调用库函数mmap，原型：void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
2、在当前进程的虚拟地址空间中，寻找一段空闲的满足要求的连续的虚拟地址
3、为此虚拟区分配一个vm_area_struct结构，接着对这个结构的各个域进行了初始化
4、将新建的虚拟区结构（vm_area_struct）插入进程的虚拟地址区域链表或树中
（二）调用内核空间的系统调用函数mmap（不同于用户空间函数），实现文件物理地址和进程虚拟地址的一一映射关系
5、为映射分配了新的虚拟地址区域后，通过待映射的文件指针，在文件描述符表中找到对应的文件描述符，通过文件描述符，链接到内核“已打开文件集”中该文件的文件结构体（struct file），每个文件结构体维护着和这个已打开文件相关各项信息。
6、通过该文件的文件结构体，链接到file_operations模块，调用内核函数mmap，其原型为：int mmap(struct file *filp, struct vm_area_struct *vma)，不同于用户空间库函数。
7、内核mmap函数通过虚拟文件系统inode模块定位到文件磁盘物理地址。
8、通过remap_pfn_range函数建立页表，即实现了文件地址和虚拟地址区域的映射关系。此时，这片虚拟地址并没有任何数据关联到主存中。
（三）进程发起对这片映射空间的访问，引发缺页异常，实现文件内容到物理内存（主存）的拷贝
注：前两个阶段仅在于创建虚拟区间并完成地址映射，但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。
9、进程的读或写操作访问虚拟地址空间这一段映射地址，通过查询页表，发现这一段地址并不在物理页面上。因为目前只建立了地址映射，真正的硬盘数据还没有拷贝到内存中，因此引发缺页异常。
10、缺页异常进行一系列判断，确定无非法操作后，内核发起请求调页过程。
11、调页过程先在交换缓存空间（swap cache）中寻找需要访问的内存页，如果没有则调用nopage函数把所缺的页从磁盘装入到主存中。
12、之后进程即可对这片主存进行读或者写的操作，如果写操作改变了其内容，一定时间后系统会自动回写脏页面到对应磁盘地址，也即完成了写入到文件的过程。
注：修改过的脏页面并不会立即更新回文件中，而是有一段时间的延迟，可以调用msync()来强制同步, 这样所写的内容就能立即保存到文件里了。
mmap和常规文件操作的区别
对linux文件系统不了解的朋友，请参阅我之前写的博文《从内核文件系统看文件读写过程》，我们首先简单的回顾一下常规文件系统操作（调用read/fread等类函数）中，函数的调用过程：
1、进程发起读文件请求。
2、内核通过查找进程文件符表，定位到内核已打开文件集上的文件信息，从而找到此文件的inode。
3、inode在address_space上查找要请求的文件页是否已经缓存在页缓存中。如果存在，则直接返回这片文件页的内容。
4、如果不存在，则通过inode定位到文件磁盘地址，将数据从磁盘复制到页缓存。之后再次发起读页面过程，进而将页缓存中的数据发给用户进程。
总结来说，常规文件操作为了提高读写效率和保护磁盘，使用了页缓存机制。这样造成读文件时需要先将文件页从磁盘拷贝到页缓存中，由于页缓存处在内核空间，不能被用户进程直接寻址，所以还需要将页缓存中数据页再次拷贝到内存对应的用户空间中。这样，通过了两次数据拷贝过程，才能完成进程对文件内容的获取任务。写操作也是一样，待写入的buffer在内核空间不能直接访问，必须要先拷贝至内核空间对应的主存，再写回磁盘中（延迟写回），也是需要两次数据拷贝。
而使用mmap操作文件中，创建新的虚拟内存区域和建立文件磁盘地址和虚拟内存区域映射这两步，没有任何文件拷贝操作。而之后访问数据时发现内存中并无数据而发起的缺页异常过程，可以通过已经建立好的映射关系，只使用一次数据拷贝，就从磁盘中将数据传入内存的用户空间中，供进程使用。
总而言之，常规文件操作需要从磁盘到页缓存再到用户主存的两次数据拷贝。而mmap操控文件，只需要从磁盘到用户主存的一次数据拷贝过程。说白了，mmap的关键点是实现了用户空间和内核空间的数据直接交互而省去了空间不同数据不通的繁琐过程。因此mmap效率更高。
mmap优点总结
由上文讨论可知，mmap优点共有一下几点：
1、对文件的读取操作跨过了页缓存，减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率。
2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内，从而被对方空间及时捕捉。
3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的。
同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据。
4、可用于实现高效的大规模数据传输。内存空间不足，是制约大数据操作的一个方面，解决方案往往是借助硬盘空间协助操作，补充内存的不足。但是进一步会造成大量的文件I/O操作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效。
五、
内核当发生访问资源冲突的时候，可以有两种锁的解决方案选择：
Spinlock 是内核中提供的一种比较常见的锁机制，自旋锁是“原地等待”的方式解决资源冲突的，即，一个线程获取了一个自旋锁后，另外一个线程期望获取该自旋锁，获取不到，只能够原地“打转”（忙等待）。由于自旋锁的这个忙等待的特性，注定了它使用场景上的限制 —— 自旋锁不应该被长时间的持有（消耗 CPU 资源）。
自旋锁的使用
在linux kernel的实现中，经常会遇到这样的场景：共享数据被中断上下文和进程上下文访问，该如何保护呢？如果只有进程上下文的访问，那么可以考虑使用semaphore或者mutex的锁机制，但是现在中断上下文也参和进来，那些可以导致睡眠的lock就不能使用了，这时候，可以考虑使用spin lock。
这里为什么把中断上下文标红加粗呢？因为在中断上下文，是不允许睡眠的（原因详见文章《Linux 中断之中断处理浅析》中的第四章），所以，这里需要的是一个不会导致睡眠的锁——spinlock。
换言之，中断上下文要用锁，首选 spinlock。
使用自旋锁，有两种方式定义一个锁：
动态的：
静态的：
DEFINE_SPINLOCK(lock);
自旋锁的死锁和解决
自旋锁不可递归，自己等待自己已经获取的锁，会导致死锁。
自旋锁可以在中断上下文中使用，但是试想一个场景：一个线程获取了一个锁，但是被中断处理程序打断，中断处理程序也获取了这个锁（但是之前已经被锁住了，无法获取到，只能自旋），中断无法退出，导致线程中后面释放锁的代码无法被执行，导致死锁。（如果确认中断中不会访问和线程中同一个锁，其实无所谓）
一、考虑下面的场景（内核抢占场景）：
（1）进程A在某个系统调用过程中访问了共享资源 R
（2）进程B在某个系统调用过程中也访问了共享资源 R
会不会造成冲突呢？假设在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，在中断返回现场的时候，发生进程切换，B启动执行，并通过系统调用访问了R，如果没有锁保护，则会出现两个thread进入临界区，导致程序执行不正确。OK，我们加上spin lock看看如何：A在进入临界区之前获取了spin lock，同样的，在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，B在访问临界区之前仍然会试图获取spin lock，这时候由于A进程持有spin lock而导致B进程进入了永久的spin……怎么破？linux的kernel很简单，在A进程获取spin lock的时候，禁止本CPU上的抢占（上面的永久spin的场合仅仅在本CPU的进程抢占本CPU的当前进程这样的场景中发生）。如果A和B运行在不同的CPU上，那么情况会简单一些：A进程虽然持有spin lock而导致B进程进入spin状态，不过由于运行在不同的CPU上，A进程会持续执行并会很快释放spin lock，解除B进程的spin状态
二、再考虑下面的场景（中断上下文场景）：
（1）运行在CPU0上的进程A在某个系统调用过程中访问了共享资源 R
（2）运行在CPU1上的进程B在某个系统调用过程中也访问了共享资源 R
（3）外设P的中断handler中也会访问共享资源 R
在这样的场景下，使用spin lock可以保护访问共享资源R的临界区吗？我们假设CPU0上的进程A持有spin lock进入临界区，这时候，外设P发生了中断事件，并且调度到了CPU1上执行，看起来没有什么问题，执行在CPU1上的handler会稍微等待一会CPU0上的进程A，等它立刻临界区就会释放spin lock的，但是，如果外设P的中断事件被调度到了CPU0上执行会怎么样？CPU0上的进程A在持有spin lock的状态下被中断上下文抢占，而抢占它的CPU0上的handler在进入临界区之前仍然会试图获取spin lock，悲剧发生了，CPU0上的P外设的中断handler永远的进入spin状态，这时候，CPU1上的进程B也不可避免在试图持有spin lock的时候失败而导致进入spin状态。为了解决这样的问题，linux kernel采用了这样的办法：如果涉及到中断上下文的访问，spin lock需要和禁止本 CPU 上的中断联合使用。
三、再考虑下面的场景（底半部场景）
linux kernel中提供了丰富的bottom half的机制，虽然同属中断上下文，不过还是稍有不同。我们可以把上面的场景简单修改一下：外设P不是中断handler中访问共享资源R，而是在的bottom half中访问。使用spin lock+禁止本地中断当然是可以达到保护共享资源的效果，但是使用牛刀来杀鸡似乎有点小题大做，这时候disable bottom half就OK了
四、中断上下文之间的竞争
同一种中断handler之间在uni core和multi core上都不会并行执行，这是linux kernel的特性。
如果不同中断handler需要使用spin lock保护共享资源，对于新的内核（不区分fast handler和slow handler），所有handler都是关闭中断的，因此使用spin lock不需要关闭中断的配合。
bottom half又分成softirq和tasklet，同一种softirq会在不同的CPU上并发执行，因此如果某个驱动中的softirq的handler中会访问某个全局变量，对该全局变量是需要使用spin lock保护的，不用配合disable CPU中断或者bottom half。
tasklet更简单，因为同一种tasklet不会多个CPU上并发。
来自 <https://blog.csdn.net/zhoutaopower/article/details/86598839>
六、
驱动里面为dao什么要有du并发、互斥的控制？如何zhi实现？讲个例子？ 并发dao（concurrency）指的版是多个执行单元同权时、并行被执行，而并发的执行单元对 共 享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions） 。 解决竞态问题的途径是保证对共享资源的互斥访问， 所谓互斥访问就是指一个执行单 元 在访问共享资源的时候，其他的执行单元都被禁止访问。 访问共享资源的代码区域被称为临界区， 临界区需要以某种互斥机 制加以保护， 中断屏蔽， 原子操作，自旋锁，和信号量都是 linux 设备驱动中可采用的互斥途径。
- spin_lock_init (&lock);
- spinlock_t lock;
- 一个是原地等待
- 一个是挂起当前进程，调度其他进程执行（睡眠）
- kzalloc 是强制清零的 kmalloc 操作；（以下描述不区分 kmalloc 和 kzalloc）
- kmalloc 分配的内存大小有限制（128KB），而 vmalloc 没有限制；
- kmalloc 可以保证分配的内存物理地址是连续的，但是 vmalloc 不能保证；
- kmalloc 分配内存的过程可以是原子过程（使用 GFP_ATOMIC），而 vmalloc 分配内存时则可能产生阻塞；
- kmalloc 分配内存的开销小，因此 kmalloc 比 vmalloc 要快；
- 用于申请内核空间的内存；
- 内存以字节为单位进行分配；
- 所分配的内存虚拟地址上连续；
Linux驱动开发面试题库
一、FIQ和IRQ区别
FIQ和IRQ是两种不同类型的中断，ARM为了支持这两种不同的中断，提供了对应的叫做FIQ和IRQ处理器模式（ARM有7种处理模式）。
一般的中断控制器里我们可以配置与控制器相连的某个中断输入是FIQ还是IRQ,所以一个中断是可以指定为FIQ或者IRQ的，为了合理，要求系统更快响应，自身处理所耗时间也很短的中断设置为FIQ，否则就设置了IRQ。
如果该中断设置为了IRQ，那么当该中断产生的时候，中断处理器通过IRQ请求线告诉ARM，ARM就知道有个IRQ中断来了，然后ARM切换到IRQ模式运行。类似的如果该中断设置为FIQ，那么当该中断产生的时候，中断处理器通过FIQ请求线告诉ARM，ARM就知道有个FIQ中断来了，然后切换到FIQ模式运行。
简单的对比的话就是FIQ比IRQ快，为什么快呢？
ARM的FIQ模式提供了更多的banked备份寄存器，r8 ～r14,SPSR；而IRQ模式提供的banked寄存器为R13,R14,SPSR，这就意味着在ARM的IRQ模式下，中断处理程序自己要保存R8到R12这几个寄存器，然后退出中断处理时程序要恢复这几个寄存器，而FIQ模式由于这几个寄存器都有banked寄存器，模式切换时CPU自动保存这些值到banked寄存器，退出FIQ模式时自动恢复，所以这个过程FIQ比IRQ快.
FIQ比IRQ有更高优先级，FIQ优先级为3，IRQ优先级为4。如果FIQ和IRQ同时产生，那么FIQ先处理；如果。
另外FIQ的入口地址是0x1c,IRQ的入口地址是0x18。
二、linux内核里申请内存的函数
kmalloc()、kzalloc()、vmalloc() 的共同特点是：
kmalloc()、kzalloc()、vmalloc() 的区别是：
https://blog.csdn.net/lu_embedded/article/details/51588902
三、中断处理分为上半部和下半部
中断处理的上半部和下半部都是不允许出现睡眠和阻塞的。但是对于下半部，并不是一刀切，不同下半部的实现方式有的不允许睡眠和阻塞（软中断和tasklet），有的是可以的（工作队列）
上半部：一般中断的中断处理函数为上半部，需要立即执行且耗时少的操作（时间太长，且如果该中断的标志是IRQF_DISABLED的话，会禁掉所有本地中断，这个函数时间长的话会对系统的性能早成严重影响）
下半部：由于上半部只能执行耗时少的操作，所以耗时长的操作就放在下半部，两个的界限并不是很明显，取决于我们要将哪个操作放在上半部还是下半部
##上半部：
中断的上半部是中断处理函数，要求做耗时少的动作，尽量迅速，一定不能休眠和阻塞
##下半部：
参阅《linux内核设计与实现》
四、
mmap基础概念
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。如下图所示：
mmap内存映射原理
mmap内存映射的实现过程，总的来说可以分为三个阶段：
（一）进程启动映射过程，并在虚拟地址空间中为映射创建虚拟映射区域
1、进程在用户空间调用库函数mmap，原型：void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
2、在当前进程的虚拟地址空间中，寻找一段空闲的满足要求的连续的虚拟地址
3、为此虚拟区分配一个vm_area_struct结构，接着对这个结构的各个域进行了初始化
4、将新建的虚拟区结构（vm_area_struct）插入进程的虚拟地址区域链表或树中
（二）调用内核空间的系统调用函数mmap（不同于用户空间函数），实现文件物理地址和进程虚拟地址的一一映射关系
5、为映射分配了新的虚拟地址区域后，通过待映射的文件指针，在文件描述符表中找到对应的文件描述符，通过文件描述符，链接到内核“已打开文件集”中该文件的文件结构体（struct file），每个文件结构体维护着和这个已打开文件相关各项信息。
6、通过该文件的文件结构体，链接到file_operations模块，调用内核函数mmap，其原型为：int mmap(struct file *filp, struct vm_area_struct *vma)，不同于用户空间库函数。
7、内核mmap函数通过虚拟文件系统inode模块定位到文件磁盘物理地址。
8、通过remap_pfn_range函数建立页表，即实现了文件地址和虚拟地址区域的映射关系。此时，这片虚拟地址并没有任何数据关联到主存中。
（三）进程发起对这片映射空间的访问，引发缺页异常，实现文件内容到物理内存（主存）的拷贝
注：前两个阶段仅在于创建虚拟区间并完成地址映射，但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。
9、进程的读或写操作访问虚拟地址空间这一段映射地址，通过查询页表，发现这一段地址并不在物理页面上。因为目前只建立了地址映射，真正的硬盘数据还没有拷贝到内存中，因此引发缺页异常。
10、缺页异常进行一系列判断，确定无非法操作后，内核发起请求调页过程。
11、调页过程先在交换缓存空间（swap cache）中寻找需要访问的内存页，如果没有则调用nopage函数把所缺的页从磁盘装入到主存中。
12、之后进程即可对这片主存进行读或者写的操作，如果写操作改变了其内容，一定时间后系统会自动回写脏页面到对应磁盘地址，也即完成了写入到文件的过程。
注：修改过的脏页面并不会立即更新回文件中，而是有一段时间的延迟，可以调用msync()来强制同步, 这样所写的内容就能立即保存到文件里了。
mmap和常规文件操作的区别
对linux文件系统不了解的朋友，请参阅我之前写的博文《从内核文件系统看文件读写过程》，我们首先简单的回顾一下常规文件系统操作（调用read/fread等类函数）中，函数的调用过程：
1、进程发起读文件请求。
2、内核通过查找进程文件符表，定位到内核已打开文件集上的文件信息，从而找到此文件的inode。
3、inode在address_space上查找要请求的文件页是否已经缓存在页缓存中。如果存在，则直接返回这片文件页的内容。
4、如果不存在，则通过inode定位到文件磁盘地址，将数据从磁盘复制到页缓存。之后再次发起读页面过程，进而将页缓存中的数据发给用户进程。
总结来说，常规文件操作为了提高读写效率和保护磁盘，使用了页缓存机制。这样造成读文件时需要先将文件页从磁盘拷贝到页缓存中，由于页缓存处在内核空间，不能被用户进程直接寻址，所以还需要将页缓存中数据页再次拷贝到内存对应的用户空间中。这样，通过了两次数据拷贝过程，才能完成进程对文件内容的获取任务。写操作也是一样，待写入的buffer在内核空间不能直接访问，必须要先拷贝至内核空间对应的主存，再写回磁盘中（延迟写回），也是需要两次数据拷贝。
而使用mmap操作文件中，创建新的虚拟内存区域和建立文件磁盘地址和虚拟内存区域映射这两步，没有任何文件拷贝操作。而之后访问数据时发现内存中并无数据而发起的缺页异常过程，可以通过已经建立好的映射关系，只使用一次数据拷贝，就从磁盘中将数据传入内存的用户空间中，供进程使用。
总而言之，常规文件操作需要从磁盘到页缓存再到用户主存的两次数据拷贝。而mmap操控文件，只需要从磁盘到用户主存的一次数据拷贝过程。说白了，mmap的关键点是实现了用户空间和内核空间的数据直接交互而省去了空间不同数据不通的繁琐过程。因此mmap效率更高。
mmap优点总结
由上文讨论可知，mmap优点共有一下几点：
1、对文件的读取操作跨过了页缓存，减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率。
2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内，从而被对方空间及时捕捉。
3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的。
同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据。
4、可用于实现高效的大规模数据传输。内存空间不足，是制约大数据操作的一个方面，解决方案往往是借助硬盘空间协助操作，补充内存的不足。但是进一步会造成大量的文件I/O操作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效。
五、
内核当发生访问资源冲突的时候，可以有两种锁的解决方案选择：
Spinlock 是内核中提供的一种比较常见的锁机制，自旋锁是“原地等待”的方式解决资源冲突的，即，一个线程获取了一个自旋锁后，另外一个线程期望获取该自旋锁，获取不到，只能够原地“打转”（忙等待）。由于自旋锁的这个忙等待的特性，注定了它使用场景上的限制 —— 自旋锁不应该被长时间的持有（消耗 CPU 资源）。
自旋锁的使用
在linux kernel的实现中，经常会遇到这样的场景：共享数据被中断上下文和进程上下文访问，该如何保护呢？如果只有进程上下文的访问，那么可以考虑使用semaphore或者mutex的锁机制，但是现在中断上下文也参和进来，那些可以导致睡眠的lock就不能使用了，这时候，可以考虑使用spin lock。
这里为什么把中断上下文标红加粗呢？因为在中断上下文，是不允许睡眠的（原因详见文章《Linux 中断之中断处理浅析》中的第四章），所以，这里需要的是一个不会导致睡眠的锁——spinlock。
换言之，中断上下文要用锁，首选 spinlock。
使用自旋锁，有两种方式定义一个锁：
动态的：
静态的：
DEFINE_SPINLOCK(lock);
自旋锁的死锁和解决
自旋锁不可递归，自己等待自己已经获取的锁，会导致死锁。
自旋锁可以在中断上下文中使用，但是试想一个场景：一个线程获取了一个锁，但是被中断处理程序打断，中断处理程序也获取了这个锁（但是之前已经被锁住了，无法获取到，只能自旋），中断无法退出，导致线程中后面释放锁的代码无法被执行，导致死锁。（如果确认中断中不会访问和线程中同一个锁，其实无所谓）
一、考虑下面的场景（内核抢占场景）：
（1）进程A在某个系统调用过程中访问了共享资源 R
（2）进程B在某个系统调用过程中也访问了共享资源 R
会不会造成冲突呢？假设在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，在中断返回现场的时候，发生进程切换，B启动执行，并通过系统调用访问了R，如果没有锁保护，则会出现两个thread进入临界区，导致程序执行不正确。OK，我们加上spin lock看看如何：A在进入临界区之前获取了spin lock，同样的，在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，B在访问临界区之前仍然会试图获取spin lock，这时候由于A进程持有spin lock而导致B进程进入了永久的spin……怎么破？linux的kernel很简单，在A进程获取spin lock的时候，禁止本CPU上的抢占（上面的永久spin的场合仅仅在本CPU的进程抢占本CPU的当前进程这样的场景中发生）。如果A和B运行在不同的CPU上，那么情况会简单一些：A进程虽然持有spin lock而导致B进程进入spin状态，不过由于运行在不同的CPU上，A进程会持续执行并会很快释放spin lock，解除B进程的spin状态
二、再考虑下面的场景（中断上下文场景）：
（1）运行在CPU0上的进程A在某个系统调用过程中访问了共享资源 R
（2）运行在CPU1上的进程B在某个系统调用过程中也访问了共享资源 R
（3）外设P的中断handler中也会访问共享资源 R
在这样的场景下，使用spin lock可以保护访问共享资源R的临界区吗？我们假设CPU0上的进程A持有spin lock进入临界区，这时候，外设P发生了中断事件，并且调度到了CPU1上执行，看起来没有什么问题，执行在CPU1上的handler会稍微等待一会CPU0上的进程A，等它立刻临界区就会释放spin lock的，但是，如果外设P的中断事件被调度到了CPU0上执行会怎么样？CPU0上的进程A在持有spin lock的状态下被中断上下文抢占，而抢占它的CPU0上的handler在进入临界区之前仍然会试图获取spin lock，悲剧发生了，CPU0上的P外设的中断handler永远的进入spin状态，这时候，CPU1上的进程B也不可避免在试图持有spin lock的时候失败而导致进入spin状态。为了解决这样的问题，linux kernel采用了这样的办法：如果涉及到中断上下文的访问，spin lock需要和禁止本 CPU 上的中断联合使用。
三、再考虑下面的场景（底半部场景）
linux kernel中提供了丰富的bottom half的机制，虽然同属中断上下文，不过还是稍有不同。我们可以把上面的场景简单修改一下：外设P不是中断handler中访问共享资源R，而是在的bottom half中访问。使用spin lock+禁止本地中断当然是可以达到保护共享资源的效果，但是使用牛刀来杀鸡似乎有点小题大做，这时候disable bottom half就OK了
四、中断上下文之间的竞争
同一种中断handler之间在uni core和multi core上都不会并行执行，这是linux kernel的特性。
如果不同中断handler需要使用spin lock保护共享资源，对于新的内核（不区分fast handler和slow handler），所有handler都是关闭中断的，因此使用spin lock不需要关闭中断的配合。
bottom half又分成softirq和tasklet，同一种softirq会在不同的CPU上并发执行，因此如果某个驱动中的softirq的handler中会访问某个全局变量，对该全局变量是需要使用spin lock保护的，不用配合disable CPU中断或者bottom half。
tasklet更简单，因为同一种tasklet不会多个CPU上并发。
来自 <https://blog.csdn.net/zhoutaopower/article/details/86598839>
六、
驱动里面为dao什么要有du并发、互斥的控制？如何zhi实现？讲个例子？ 并发dao（concurrency）指的版是多个执行单元同权时、并行被执行，而并发的执行单元对 共 享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions） 。 解决竞态问题的途径是保证对共享资源的互斥访问， 所谓互斥访问就是指一个执行单 元 在访问共享资源的时候，其他的执行单元都被禁止访问。 访问共享资源的代码区域被称为临界区， 临界区需要以某种互斥机 制加以保护， 中断屏蔽， 原子操作，自旋锁，和信号量都是 linux 设备驱动中可采用的互斥途径。
- spin_lock_init (&lock);
- spinlock_t lock;
- 一个是原地等待
- 一个是挂起当前进程，调度其他进程执行（睡眠）
- kzalloc 是强制清零的 kmalloc 操作；（以下描述不区分 kmalloc 和 kzalloc）
- kmalloc 分配的内存大小有限制（128KB），而 vmalloc 没有限制；
- kmalloc 可以保证分配的内存物理地址是连续的，但是 vmalloc 不能保证；
- kmalloc 分配内存的过程可以是原子过程（使用 GFP_ATOMIC），而 vmalloc 分配内存时则可能产生阻塞；
- kmalloc 分配内存的开销小，因此 kmalloc 比 vmalloc 要快；
- 用于申请内核空间的内存；
- 内存以字节为单位进行分配；
- 所分配的内存虚拟地址上连续；
Linux驱动开发面试题库
一、FIQ和IRQ区别
FIQ和IRQ是两种不同类型的中断，ARM为了支持这两种不同的中断，提供了对应的叫做FIQ和IRQ处理器模式（ARM有7种处理模式）。
一般的中断控制器里我们可以配置与控制器相连的某个中断输入是FIQ还是IRQ,所以一个中断是可以指定为FIQ或者IRQ的，为了合理，要求系统更快响应，自身处理所耗时间也很短的中断设置为FIQ，否则就设置了IRQ。
如果该中断设置为了IRQ，那么当该中断产生的时候，中断处理器通过IRQ请求线告诉ARM，ARM就知道有个IRQ中断来了，然后ARM切换到IRQ模式运行。类似的如果该中断设置为FIQ，那么当该中断产生的时候，中断处理器通过FIQ请求线告诉ARM，ARM就知道有个FIQ中断来了，然后切换到FIQ模式运行。
简单的对比的话就是FIQ比IRQ快，为什么快呢？
ARM的FIQ模式提供了更多的banked备份寄存器，r8 ～r14,SPSR；而IRQ模式提供的banked寄存器为R13,R14,SPSR，这就意味着在ARM的IRQ模式下，中断处理程序自己要保存R8到R12这几个寄存器，然后退出中断处理时程序要恢复这几个寄存器，而FIQ模式由于这几个寄存器都有banked寄存器，模式切换时CPU自动保存这些值到banked寄存器，退出FIQ模式时自动恢复，所以这个过程FIQ比IRQ快.
FIQ比IRQ有更高优先级，FIQ优先级为3，IRQ优先级为4。如果FIQ和IRQ同时产生，那么FIQ先处理；如果。
另外FIQ的入口地址是0x1c,IRQ的入口地址是0x18。
二、linux内核里申请内存的函数
kmalloc()、kzalloc()、vmalloc() 的共同特点是：
kmalloc()、kzalloc()、vmalloc() 的区别是：
https://blog.csdn.net/lu_embedded/article/details/51588902
三、中断处理分为上半部和下半部
中断处理的上半部和下半部都是不允许出现睡眠和阻塞的。但是对于下半部，并不是一刀切，不同下半部的实现方式有的不允许睡眠和阻塞（软中断和tasklet），有的是可以的（工作队列）
上半部：一般中断的中断处理函数为上半部，需要立即执行且耗时少的操作（时间太长，且如果该中断的标志是IRQF_DISABLED的话，会禁掉所有本地中断，这个函数时间长的话会对系统的性能早成严重影响）
下半部：由于上半部只能执行耗时少的操作，所以耗时长的操作就放在下半部，两个的界限并不是很明显，取决于我们要将哪个操作放在上半部还是下半部
##上半部：
中断的上半部是中断处理函数，要求做耗时少的动作，尽量迅速，一定不能休眠和阻塞
##下半部：
参阅《linux内核设计与实现》
四、
mmap基础概念
mmap是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用read,write等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。如下图所示：
mmap内存映射原理
mmap内存映射的实现过程，总的来说可以分为三个阶段：
（一）进程启动映射过程，并在虚拟地址空间中为映射创建虚拟映射区域
1、进程在用户空间调用库函数mmap，原型：void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
2、在当前进程的虚拟地址空间中，寻找一段空闲的满足要求的连续的虚拟地址
3、为此虚拟区分配一个vm_area_struct结构，接着对这个结构的各个域进行了初始化
4、将新建的虚拟区结构（vm_area_struct）插入进程的虚拟地址区域链表或树中
（二）调用内核空间的系统调用函数mmap（不同于用户空间函数），实现文件物理地址和进程虚拟地址的一一映射关系
5、为映射分配了新的虚拟地址区域后，通过待映射的文件指针，在文件描述符表中找到对应的文件描述符，通过文件描述符，链接到内核“已打开文件集”中该文件的文件结构体（struct file），每个文件结构体维护着和这个已打开文件相关各项信息。
6、通过该文件的文件结构体，链接到file_operations模块，调用内核函数mmap，其原型为：int mmap(struct file *filp, struct vm_area_struct *vma)，不同于用户空间库函数。
7、内核mmap函数通过虚拟文件系统inode模块定位到文件磁盘物理地址。
8、通过remap_pfn_range函数建立页表，即实现了文件地址和虚拟地址区域的映射关系。此时，这片虚拟地址并没有任何数据关联到主存中。
（三）进程发起对这片映射空间的访问，引发缺页异常，实现文件内容到物理内存（主存）的拷贝
注：前两个阶段仅在于创建虚拟区间并完成地址映射，但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。
9、进程的读或写操作访问虚拟地址空间这一段映射地址，通过查询页表，发现这一段地址并不在物理页面上。因为目前只建立了地址映射，真正的硬盘数据还没有拷贝到内存中，因此引发缺页异常。
10、缺页异常进行一系列判断，确定无非法操作后，内核发起请求调页过程。
11、调页过程先在交换缓存空间（swap cache）中寻找需要访问的内存页，如果没有则调用nopage函数把所缺的页从磁盘装入到主存中。
12、之后进程即可对这片主存进行读或者写的操作，如果写操作改变了其内容，一定时间后系统会自动回写脏页面到对应磁盘地址，也即完成了写入到文件的过程。
注：修改过的脏页面并不会立即更新回文件中，而是有一段时间的延迟，可以调用msync()来强制同步, 这样所写的内容就能立即保存到文件里了。
mmap和常规文件操作的区别
对linux文件系统不了解的朋友，请参阅我之前写的博文《从内核文件系统看文件读写过程》，我们首先简单的回顾一下常规文件系统操作（调用read/fread等类函数）中，函数的调用过程：
1、进程发起读文件请求。
2、内核通过查找进程文件符表，定位到内核已打开文件集上的文件信息，从而找到此文件的inode。
3、inode在address_space上查找要请求的文件页是否已经缓存在页缓存中。如果存在，则直接返回这片文件页的内容。
4、如果不存在，则通过inode定位到文件磁盘地址，将数据从磁盘复制到页缓存。之后再次发起读页面过程，进而将页缓存中的数据发给用户进程。
总结来说，常规文件操作为了提高读写效率和保护磁盘，使用了页缓存机制。这样造成读文件时需要先将文件页从磁盘拷贝到页缓存中，由于页缓存处在内核空间，不能被用户进程直接寻址，所以还需要将页缓存中数据页再次拷贝到内存对应的用户空间中。这样，通过了两次数据拷贝过程，才能完成进程对文件内容的获取任务。写操作也是一样，待写入的buffer在内核空间不能直接访问，必须要先拷贝至内核空间对应的主存，再写回磁盘中（延迟写回），也是需要两次数据拷贝。
而使用mmap操作文件中，创建新的虚拟内存区域和建立文件磁盘地址和虚拟内存区域映射这两步，没有任何文件拷贝操作。而之后访问数据时发现内存中并无数据而发起的缺页异常过程，可以通过已经建立好的映射关系，只使用一次数据拷贝，就从磁盘中将数据传入内存的用户空间中，供进程使用。
总而言之，常规文件操作需要从磁盘到页缓存再到用户主存的两次数据拷贝。而mmap操控文件，只需要从磁盘到用户主存的一次数据拷贝过程。说白了，mmap的关键点是实现了用户空间和内核空间的数据直接交互而省去了空间不同数据不通的繁琐过程。因此mmap效率更高。
mmap优点总结
由上文讨论可知，mmap优点共有一下几点：
1、对文件的读取操作跨过了页缓存，减少了数据的拷贝次数，用内存读写取代I/O读写，提高了文件读取效率。
2、实现了用户空间和内核空间的高效交互方式。两空间的各自修改操作可以直接反映在映射的区域内，从而被对方空间及时捕捉。
3、提供进程间共享内存及相互通信的方式。不管是父子进程还是无亲缘关系的进程，都可以将自身用户空间映射到同一个文件或匿名映射到同一片区域。从而通过各自对映射区域的改动，达到进程间通信和进程间共享的目的。
同时，如果进程A和进程B都映射了区域C，当A第一次读取C时通过缺页从磁盘复制文件页到内存中；但当B再读C的相同页面时，虽然也会产生缺页异常，但是不再需要从磁盘中复制文件过来，而可直接使用已经保存在内存中的文件数据。
4、可用于实现高效的大规模数据传输。内存空间不足，是制约大数据操作的一个方面，解决方案往往是借助硬盘空间协助操作，补充内存的不足。但是进一步会造成大量的文件I/O操作，极大影响效率。这个问题可以通过mmap映射很好的解决。换句话说，但凡是需要用磁盘空间代替内存的时候，mmap都可以发挥其功效。
五、
内核当发生访问资源冲突的时候，可以有两种锁的解决方案选择：
Spinlock 是内核中提供的一种比较常见的锁机制，自旋锁是“原地等待”的方式解决资源冲突的，即，一个线程获取了一个自旋锁后，另外一个线程期望获取该自旋锁，获取不到，只能够原地“打转”（忙等待）。由于自旋锁的这个忙等待的特性，注定了它使用场景上的限制 —— 自旋锁不应该被长时间的持有（消耗 CPU 资源）。
自旋锁的使用
在linux kernel的实现中，经常会遇到这样的场景：共享数据被中断上下文和进程上下文访问，该如何保护呢？如果只有进程上下文的访问，那么可以考虑使用semaphore或者mutex的锁机制，但是现在中断上下文也参和进来，那些可以导致睡眠的lock就不能使用了，这时候，可以考虑使用spin lock。
这里为什么把中断上下文标红加粗呢？因为在中断上下文，是不允许睡眠的（原因详见文章《Linux 中断之中断处理浅析》中的第四章），所以，这里需要的是一个不会导致睡眠的锁——spinlock。
换言之，中断上下文要用锁，首选 spinlock。
使用自旋锁，有两种方式定义一个锁：
动态的：
静态的：
DEFINE_SPINLOCK(lock);
自旋锁的死锁和解决
自旋锁不可递归，自己等待自己已经获取的锁，会导致死锁。
自旋锁可以在中断上下文中使用，但是试想一个场景：一个线程获取了一个锁，但是被中断处理程序打断，中断处理程序也获取了这个锁（但是之前已经被锁住了，无法获取到，只能自旋），中断无法退出，导致线程中后面释放锁的代码无法被执行，导致死锁。（如果确认中断中不会访问和线程中同一个锁，其实无所谓）
一、考虑下面的场景（内核抢占场景）：
（1）进程A在某个系统调用过程中访问了共享资源 R
（2）进程B在某个系统调用过程中也访问了共享资源 R
会不会造成冲突呢？假设在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，在中断返回现场的时候，发生进程切换，B启动执行，并通过系统调用访问了R，如果没有锁保护，则会出现两个thread进入临界区，导致程序执行不正确。OK，我们加上spin lock看看如何：A在进入临界区之前获取了spin lock，同样的，在A访问共享资源R的过程中发生了中断，中断唤醒了沉睡中的，优先级更高的B，B在访问临界区之前仍然会试图获取spin lock，这时候由于A进程持有spin lock而导致B进程进入了永久的spin……怎么破？linux的kernel很简单，在A进程获取spin lock的时候，禁止本CPU上的抢占（上面的永久spin的场合仅仅在本CPU的进程抢占本CPU的当前进程这样的场景中发生）。如果A和B运行在不同的CPU上，那么情况会简单一些：A进程虽然持有spin lock而导致B进程进入spin状态，不过由于运行在不同的CPU上，A进程会持续执行并会很快释放spin lock，解除B进程的spin状态
二、再考虑下面的场景（中断上下文场景）：
（1）运行在CPU0上的进程A在某个系统调用过程中访问了共享资源 R
（2）运行在CPU1上的进程B在某个系统调用过程中也访问了共享资源 R
（3）外设P的中断handler中也会访问共享资源 R
在这样的场景下，使用spin lock可以保护访问共享资源R的临界区吗？我们假设CPU0上的进程A持有spin lock进入临界区，这时候，外设P发生了中断事件，并且调度到了CPU1上执行，看起来没有什么问题，执行在CPU1上的handler会稍微等待一会CPU0上的进程A，等它立刻临界区就会释放spin lock的，但是，如果外设P的中断事件被调度到了CPU0上执行会怎么样？CPU0上的进程A在持有spin lock的状态下被中断上下文抢占，而抢占它的CPU0上的handler在进入临界区之前仍然会试图获取spin lock，悲剧发生了，CPU0上的P外设的中断handler永远的进入spin状态，这时候，CPU1上的进程B也不可避免在试图持有spin lock的时候失败而导致进入spin状态。为了解决这样的问题，linux kernel采用了这样的办法：如果涉及到中断上下文的访问，spin lock需要和禁止本 CPU 上的中断联合使用。
三、再考虑下面的场景（底半部场景）
linux kernel中提供了丰富的bottom half的机制，虽然同属中断上下文，不过还是稍有不同。我们可以把上面的场景简单修改一下：外设P不是中断handler中访问共享资源R，而是在的bottom half中访问。使用spin lock+禁止本地中断当然是可以达到保护共享资源的效果，但是使用牛刀来杀鸡似乎有点小题大做，这时候disable bottom half就OK了
四、中断上下文之间的竞争
同一种中断handler之间在uni core和multi core上都不会并行执行，这是linux kernel的特性。
如果不同中断handler需要使用spin lock保护共享资源，对于新的内核（不区分fast handler和slow handler），所有handler都是关闭中断的，因此使用spin lock不需要关闭中断的配合。
bottom half又分成softirq和tasklet，同一种softirq会在不同的CPU上并发执行，因此如果某个驱动中的softirq的handler中会访问某个全局变量，对该全局变量是需要使用spin lock保护的，不用配合disable CPU中断或者bottom half。
tasklet更简单，因为同一种tasklet不会多个CPU上并发。
来自 <https://blog.csdn.net/zhoutaopower/article/details/86598839>
六、
驱动里面为dao什么要有du并发、互斥的控制？如何zhi实现？讲个例子？ 并发dao（concurrency）指的版是多个执行单元同权时、并行被执行，而并发的执行单元对 共 享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions） 。 解决竞态问题的途径是保证对共享资源的互斥访问， 所谓互斥访问就是指一个执行单 元 在访问共享资源的时候，其他的执行单元都被禁止访问。 访问共享资源的代码区域被称为临界区， 临界区需要以某种互斥机 制加以保护， 中断屏蔽， 原子操作，自旋锁，和信号量都是 linux 设备驱动中可采用的互斥途径。
- spin_lock_init (&lock);
- spinlock_t lock;
- 一个是原地等待
- 一个是挂起当前进程，调度其他进程执行（睡眠）
- kzalloc 是强制清零的 kmalloc 操作；（以下描述不区分 kmalloc 和 kzalloc）
- kmalloc 分配的内存大小有限制（128KB），而 vmalloc 没有限制；
- kmalloc 可以保证分配的内存物理地址是连续的，但是 vmalloc 不能保证；
- kmalloc 分配内存的过程可以是原子过程（使用 GFP_ATOMIC），而 vmalloc 分配内存时则可能产生阻塞；
- kmalloc 分配内存的开销小，因此 kmalloc 比 vmalloc 要快；
- 用于申请内核空间的内存；
- 内存以字节为单位进行分配；
- 所分配的内存虚拟地址上连续；
266
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
