@
- 嵌入式软件工程师面试题目整理（二）
- linux中内核空间及用户空间的区别？用户空间与内核通信方式有哪些？
- 字符设备和块设备的区别，请分别列举一些实际的设备说出它们是属于哪一类设备
- linux中系统调用过程？如:应用程序中read()在linux中执行过程即从用户空间到内核空间？
- 查看驱动模块中打印信息应该使用什么命令？如何查看内核中已有的字符设备的信息？如何查看正在使用的有哪些中断号？
- copy_to_user()和copy_from_user()主要用于实现什么功能？一般用于file_operations结构的哪些函数里面？
- 请简述主设备号和次设备号的用途。如果执行mknod chartest c 4 64，创建chartest设备。请分析chartest使用的是那一类设备驱动程序。
- 设备驱动程序中如何注册一个字符设备？分别解释一下它的几个参数的含义。
- 字符型驱动设备怎么创建设备文件?
- insmod 一个驱动模块，会执行模块中的哪个函数？rmmod呢？这两个函数在设计上要注意哪些？遇到过卸载驱动出现异常没？是什么问题引起的？
- 设备驱动模型三个重要成员是？platform总线的匹配规则是？在具体应用上要不要先注册驱动再注册设备？有先后顺序没？
- 内核函数mmap的实现原理，机制？
- 申请内存的方式
- IIC原理，总线框架，设备编写方法
- Linux中的用户模式和内核模式是什么含意
- 怎样申请大块内核内存？
- 用户进程间通信主要哪几种方式
- 内核配置编译及Makefile?
- 谈谈对Volatile关键字的理解
- framebuffer机制
- spinlock与信号量的区别
- linux中的同步机制
- 自旋锁和信号量在互斥使用时需要注意哪些？在中断服务程序里面的互斥是使用自旋锁还是信号量？还是两者都能用？为什么？
- 驱动里面为什么要有并发、互斥的控制？如何实现？讲个例子？
- linux中断实现机制、tasklet和workqueue的区别和底层实现的区别，为什么要区分中断上半部和中断下半部
- 中断和轮询哪个效率高？怎样决定是采用中断方式还是采用轮询方式去实现驱动？
- 写一个中断服务需要注意哪些？如果中断产生之后要做比较多的事情你是怎么做的？
- IRQ和FIQ有什么区别，在CPU里面是是怎么做的？
- Linux软中断和工作队列的作用是什么
嵌入式软件工程师面试题目整理（二）
linux中内核空间及用户空间的区别？用户空间与内核通信方式有哪些？
区别：
1.内和空间和用户空间的划分
Linux简化了分段机制，使得虚拟地址与线性地址总是一致，因此，Linux的虚拟地址空间也为0~4G.Linux内核将这4G字节的空间分为两部分。将最高的1G字节(从虚拟地址0xC0000000到0xFFFFFFFF)，供内核使用，称为"内核空间".而将较低的3G字节(从虚拟地址 0x00000000到0xBFFFFFFF)，供各个进程使用，称为"用户空间)。因为每个进程可以通过系统调用进入内核，因此，Linux内核由系统内的所有进程共享。于是，从具体进程的角度来看，每个进程可以拥有4G字节的虚拟空间。
2.存储内容不同
内核空间中存放的是内核代码和数据，而进程的用户空间中存放的是用户程序的代码和数据。不管是内核空间还是用户空间，它们都处于虚拟空间中。
下面总结了7种方式，主要对以前不是很熟悉的方式做了编程实现，以便加深印象。
3.其他
内核空间和用户空间上不同太多了，说不完，比如用户态的链表和内核链表不一样;用户态用printf,内核态用printk;用户态每个应用程序空间是虚拟的，相对独立的，内核态中却不是独立的，所以编程要非常小心。等等。
用户空间与内核通信方式
见前Linux部分
字符设备和块设备的区别，请分别列举一些实际的设备说出它们是属于哪一类设备
字符设备：字符设备是个能够像字节流（类似文件）一样被访问的设备，由字符设备驱动程序来实现这种特性。字符设备驱动程序通常至少实现open,close,read和write系统调用。字符终端、串口、鼠标、键盘、摄像头、声卡和显卡等就是典型的字符设备。
块设备：和字符设备类似，块设备也是通过/dev目录下的文件系统节点来访问。块设备上能够容纳文件系统，如：u盘，SD卡，磁盘等。
字符设备和块设备的区别仅仅在于内核内部管理数据的方式，也就是内核及驱动程序之间的软件接口，而这些不同对用户来讲是透明的。在内核中，和字符驱动程序相比，块驱动程序具有完全不同的接口。
公众号：嵌入式与Linux那些事 CSDN： 嵌入式与Linux那些事 来源网络，转载声明
linux中系统调用过程？如:应用程序中read()在linux中执行过程即从用户空间到内核空间？
必须知道的知识：
(1) 在Linux文件系统中，每个文件都用一个struct inode结构体来描述，这个结构体记录了这个文件的所有信息，例如文件类型，访问权限等。
(2) 在linux操作系统中，每个驱动程序在应用层的/dev目录或者其他如/sys目录下都会有一个文件与之对应。
(3) 在linux操作系统中, 每个驱动程序都有一个设备号。
(4) 在linux操作系统中，每打开一次文件，Linux操作系统会在VFS层分配一个struct file结构体来描述打开的文件。
注意：常常我们认为，struct inode描述的是文件的静态信息，即这些信息很少会改变，而struct file描述的是动态信息，即对文件的操作的时候，struct file里面的信息经常会发生变化。典型的是struct file结构体里面的f_ops(记录当前文件的位移量)，每次读写一个普通文件时f_ops的值都会发生改变。
通过上图我们可以知道，如果想访问底层设备，就必须打开对应的设备文件。也就是在这个打开的过程中，Linux内核将应用层和对应的驱动程序关联起来。
(1) 当open函数打开设备文件时，可以根据设备文件对应的struct inode结构体描述的信息，可以知道接下来要操作的设备类型（字符设备还是块设备），还会分配一个struct file结构体。
(2) 根据struct inode结构体里面记录的设备号，可以找到对应的驱动程序。这里以字符设备为例。在Linux操作系统中每个字符设备都有一个struct cdev结构体。此结构体描述了字符设备所有信息，其中最重要的一项就是字符设备的操作函数接口。
(3) 找到struct cdev结构体后，linux内核就会将struct cdev结构体所在的内存空间首地址记录在struct inode结构体i_cdev成员中，将struct cdev结构体中的记录的函数操作接口地址记录在struct file结构体的f_ops成员中。
(4) 任务完成，VFS层会给应用返回一个文件描述符（fd）。这个fd是和struct file结构体对应的。接下来上层应用程序就可以通过fd找到struct file，然后在有struct file找到操作字符设备的函数接口了。
公众号：嵌入式与Linux那些事 CSDN： 嵌入式与Linux那些事 来源网络，转载声明
总结
1.应用层调用open函数，在VFS层中找到struct inode结构体->>判断是字符设备还是块设备,根据设备号，可以找到对应的驱动程序
2.在驱动层中，每个字符设备都有一个struct cdev结构体,这个结构体通过struct inode结构体中的i_cdev把连接起VFS层和驱动层，struct cdev结构体描述了字符设备所有信息，其中最重要的一项就是字符设备的操作函数接口
3.struct cdev结构体中的struct file结构体记录了操作字符设备的一些函数，比如open read write函数等。
struct file结构体其实是在VFS层的，通过struct file结构体指针指向驱动层的struct file结构体将驱动层函数和VFS层链接起来
4.任务完成，VFS层会给应用返回一个文件描述符（fd）。这个fd是和struct file结构体对应的。
查看驱动模块中打印信息应该使用什么命令？如何查看内核中已有的字符设备的信息？如何查看正在使用的有哪些中断号？
1) 查看驱动模块中打印信息的命令：dmesg
2) 查看字符设备信息可以用lsmod 和modprobe，ismod可以查看模块的依赖关系，modprobe在加载模块时会加载其他依赖的 模块。
3) 显示当前使用的中断号cat /proc/interrupt
copy_to_user()和copy_from_user()主要用于实现什么功能？一般用于file_operations结构的哪些函数里面？
由于内核空间和用户空间是不能互相访问的，如果需要访问就必须借助内核函数进行数据读写。copy_to_user():完成内核空间到用户空间的复制，copy_from_user()：是完成用户空间到内核空间的复制。一般用于file_operations结构里的read,write,ioctl等内存数据交换作用的函数。当然，如果ioctl没有用到内存数据复制，那么就不会用到这两个函数。
请简述主设备号和次设备号的用途。如果执行mknod chartest c 4 64，创建chartest设备。请分析chartest使用的是那一类设备驱动程序。
1）主设备号：主设备号标识设备对应的特定的驱动程序。虽然现代的linux内核允许多个驱动程序共享主设备号，但我们看待的大多数设备仍然按照“一个主设备对应一个驱动程序”的原则组织。
次设备号：次设备号由内核使用，用于确定由主设备号对应驱动程序中的各个设备。。依赖于驱动程序的编写方式，我们可以通过次设备号获得一个指向内核设备的直接指针，也可将此设备号当作设备本地数组的索引。
2）chartest 表示设备节点，4表示主设备号，64表示次设备号。（感觉类似于串口终端或者字符设备终端）。
设备驱动程序中如何注册一个字符设备？分别解释一下它的几个参数的含义。
注册一个字符设备驱动有两种方法：
1） void cdev_init(struct cdev *cdev, struct file_operations *fops)
该注册函数可以将cdev结构嵌入到自己的设备特定的结构中。cdev是一个指向结构体cdev的指针，而fops是指向一个类似于f file_operations结构（可以是file_operations结构，但不限于该结构）的指针。
2） int register_chrdev(unsigned int major, const char *namem , struct file operations *fopen);
该注册函数是早期的注册函数，major是设备的主设备号，name是驱动程序的名称，而fops是默认的file_operations结构（这是只限于file_operations结构）。对于register_chrdev的调用将为给定的主设备号注册0－255作为次设备号，并为每个 设备建 立一个对应的默认cdev结构。
字符型驱动设备怎么创建设备文件?
手动创建：mknod /dev/led c 250 0 其中dev/led 为设备节点 ,c 代表字符设备, 250代表主设备号, 0代表次设备号。
还有UDEV/MDEV自动创建设备文件的方式，UDEV/MDEV是运行在用户态的程序，可以动态管理设备文件，包括创建和删除设备文件，运行在用户态意味着系统要运行之后。在 /etc/init.d/rcS 脚本文件中会执行 mdev -s 自动创建设备节点。
insmod 一个驱动模块，会执行模块中的哪个函数？rmmod呢？这两个函数在设计上要注意哪些？遇到过卸载驱动出现异常没？是什么问题引起的？
答： insmod调用init函数，rmmod调用exit函数。这两个函数在设计时要注意什么？卸载模块时曾出现卸载失败的情形，原因是存在进程正在使用模块，检查代码后发现产生了死锁的问题。
要注意在init函数中申请的资源在exit函数中要释放，包括存储，ioremap，定时器，工作队列等等。也就是一个模块注册进内核，退出内核时要清理所带来的影响，带走一切不留下一点痕迹。
在LCD驱动的 file_opreations结构体中有个relase函数，就算没有用到也要定义
设备驱动模型三个重要成员是？platform总线的匹配规则是？在具体应用上要不要先注册驱动再注册设备？有先后顺序没？
设备驱动模型三个重要成员是 总线、设备、驱动；
platfoem总线的匹配规则是：要匹配的设备和驱动都要注册，设备可以在设备树里注册，也可以通过代码注册设备，匹配成功会去调用驱动程序里的probe函数（probe函数在这个platform_driver结构体中注册）。
内核函数mmap的实现原理，机制？
mmap系统调用（功能）
void* mmap ( void * addr , size_t len , int prot , int flags ,int fd , off_t offset )
内存映射函数mmap, 负责把文件内容映射到进程的虚拟内存空间, 通过对这段内存的读取和修改，来实现对文件的读取和修改,而不需要再调用read，write等操作。
列举最少3种你所知道的嵌入式的体系结构，并请说明什么是ARM体系结构。
arm,mips,x86
三种架构的区别
1. ARM
ARM是高级精简指令集的简称（Advanced RISC Machine），它是一个32位的精简指令集架构，但也配备16位指令集，一般来讲比等价32位代码节省达35%，却能保留32位系统的所有优势。
ARM处理器的主要特点是：
体积小、低功耗、低成本、高性能——ARM被广泛应用在嵌入式系统中的最重要的原因。
支持Thumb（16位）/ARM（32位）双指令集，能很好的兼容8位/16位器件；
大量使用寄存器，指令执行速度更快；
大多数数据操作都在寄存器中完成；
寻址方式灵活简单，执行效率高；
指令长度固定；
Load_store结构：在RISC中，所有的计算都要求在寄存器中完成。而寄存器和内存的通信则由单独的指令来完成。而在CSIC中，CPU是可以直接对内存进行操作的。
流水线处理方式。
2. MIPS
MIPS架构（英语：MIPS architecture，为Microprocessor without interlocked piped stages architecture的缩写，亦为Millions of Instructions Per Second的相关语），是一种采取精简指令集（RISC）的处理器架构，1981年出现，由MIPS科技公司开发并授权，广泛被使用在许多电子产品、网络设备、个人娱乐装置与商业装置上。最早的MIPS架构是32位，最新的版本已经变成64位。
它的基本特点是：
包含大量的寄存器、指令数和字符；
可视的管道延时时隙；
这些特性使MIPS架构能够提供最高的每平方毫米性能和当今SoC设计中最低的能耗。
3. X86
X86架构是芯片巨头Intel设计制造的一种微处理器体系结构的统称。如果这样说你不理解，那么当我说出8086,80286等这样的词汇时，相信你肯定马上就理解了，正是基于此，X86架构这个名称被广为人知。
如今，我们所用的PC绝大部分都是X86架构。可见X86架构普及程度，这也和Intel的霸主地位密切相关。
x86采用CISC（Complex Instruction Set Computer，复杂指令集计算机）架构。与采用RISC不同的是，在CISC处理器中，程序的各条指令是按顺序串行执行的，每条指令中的各个操作也是按顺序串行执行的。顺序执行的优点是控制简单，但计算机各部分的利用率不高，执行速度慢。
总结：
申请内存的方式
见之前Linux部分整理
IIC原理，总线框架，设备编写方法
见之前Linux部分整理
Linux中的用户模式和内核模式是什么含意
见之前Linux部分整理
怎样申请大块内核内存？
vmalloc
用户进程间通信主要哪几种方式
见之前操作系统部分整理
内核配置编译及Makefile?
最近在学习Linux内核的配置、编译及Makefile文件。今天总结一下学习成果，分享给大家_
1.解压缩打补丁
首先是解压缩你获取到的Linux内核。这里我用到的是linux.2.22.6版本的内核。在Linux下命令行通过tar xjf linux.2.22.6.tar.bz2解压内核。然后，如果你需要对这个内核打补丁的话，用patch命令：patch -px <../linux.2.22.6.patch。这里的px指的是忽略掉补丁文件中描述的第几个斜杠。也就是忽略前x个目录。
--- linux-2.6.22.6/arch/arm/configs/s3c2410_defconfig
+++ linux-2.6.22.6_jz2440/arch/arm/configs/s3c2410_defconfig
如果你此刻就在内核的根目录下，即linux-2.6.22.6下，也就是说打补丁需要忽略掉一个斜杠的目录。那么打补丁的命令就是patch -p1 <../linux.2.22.6.patch。
2.配置内核
现在补丁已经打好了，接下来就是配置内核了。这里配置有3种方法：
1>直接进行make menuconfig。这是最麻烦的一种方法，所有的配置都需要你来操作。
2>在默认配置上自己修改，也就是修改defconfig文件。使用 find -name "defconfig"查找你的架构对应的默认配置文件。我是在arch/arm/configs找到自己板子的默认配置文件。执行defconfig文件： make XXX_defconfig。XXX是你具体使用的板子型号。执行这一操作后，结果保存在.config文件。然后再执行make menuconfig命令。这时的配置就是在默认配置上稍加修改就可以了。
3>使用厂家的配置文件。如果你的硬件有厂家提供的config文件那是最轻松的。直接cp XXX .config。然后执行make menuconfig。
这里详细给大家讲一下内核的配置。Linux的内核配置，就是为了生成.config文件。因为在编译时需要用.config文件生成其他相关配置文件。我们的配置项大多是例如CONFIG_XXXDRIVER，这里的XXXDRIVER指的是各种驱动。我们需要告诉内核，这些驱动是编译进内核，还是编译成模块。通过查找CONFIG_XXXDRIVER，我们可以发现，它出现在四个地方：
1>C源代码
2>子目录Makefile:drivers/XXX/Makefile
3>include/config/auto.conf
4>include/linux/autoconf.h
这里首先说明：.config文件在进行内核编译时（make uImage）生成了include/config/auto.conf和include/linux/autoconf.h。通过查看C源代码我们发现CONFIG_XXXDRIVER是一个宏定义，等于一个常量。在include/linux/autoconf.h中宏定义CONFIG_XXXDRIVER为一个常量，可能是0或1。那么现在有一个问题，就是CONFIG_XXXDRIVER到底被编译进内核还是编译成一个模块呢？这在C语言中是无法进行区分的，这种区分体现在哪里呢？这种区分体现在子目录的Makefile文件中。在子目录的Makefile中，若有 obj -y += XXX.o则表示XXX.c被编译进内核；obj -m +=XXX.o则表示XXX被编译成模块，为XXX.ko。include/config/auto.conf文件则是对CONFIG_XXXDRIVER进行赋值，为y时表示编译进内核，为m时表示编译成独立模块。
#这里是include/config/auto.conf的部分内容
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22.6
# Sun Nov 27 18:34:38 2016
#
CONFIG_CPU_S3C244X=y
CONFIG_CPU_COPY_V4WB=y
CONFIG_CRYPTO_CBC=y
CONFIG_CPU_S3C2410_DMA=y
CONFIG_CRYPTO_ECB=m
CONFIG_SMDK2440_CPU2440=y
复制代码
复制代码
#这里是drivers/i2c/Makefile
# Makefile for the i2c core.
#
obj-$(CONFIG_I2C_BOARDINFO) += i2c-boardinfo.o
obj-$(CONFIG_I2C) += i2c-core.o
obj-$(CONFIG_I2C_CHARDEV) += i2c-dev.o
obj-y += busses/ chips/ algos/
ifeq ($(CONFIG_I2C_DEBUG_CORE),y)
EXTRA_CFLAGS += -DDEBUG
endif
3.编译内核
通过上面的描述，我们可以知道，在每个driver下，都有一个Makefile文件。来定义这个驱动是编译进内核还是编译成模块。这里稍稍提一下。上面我们讲到了在Makefile中单个文件怎样编译进内核和编译成模块。但是如果有两个以上的文件该如何书写呢？这里举个例子：obj -y += a.o b.o就表示将a.c和b.c编译进内核。
obj -m += ab.o
ab -objs := a.o b.o
就可以表示将a.c和b.c共同编译成为一个模块。过程就是 a.c生成a.o , b.c生成b.o。a.o 和b.o共同生成ab.ko。在以往的对uboot启动内核的代码分析中，我们提到过编译内核生成的uImage是由两部分组成的：头部+Linux内核。这个头部包含了很多初始化的参数信息，例如内核的加载地址和入口地址。在编译内核时，我们直接执行make uImage即可。那么在文件中是怎样定义uImage的呢？又是怎样生成uImage的呢？
首先，我们通过查找Makefile，发现uImage在arch/arm/Makefile中，而这个架构目录下的Makefile被包含进顶层目录的Makefile中。这样我们在执行 make uImage时，顶层目录的Makefile就可以调用架构子目录下的Makefile，实现对内核的编译，生成uImage。
顶层目录下Makefile中相关命令：
include $(srctree)/arch/$(ARCH)/Makefile
架构目录下Makefile相关命令：
zImage Image xipImage bootpImage uImage: vmlinux
这就是刚刚所说的顶层Makefile调用架构目录下Makefile，架构目录下Makefile生成uImage,而且依赖于vmlinux文件。下面我们就开始讲解如何生成vmlinux文件。在顶层Makefile中，我们找到了有关生成vmlinux的大部分命令。
顶层目录Makefile：
init-y := init/
init-y := $(patsubst %/, %/built-in.o, $(init-y))
core-y := usr/
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
core-y := $(patsubst %/, %/built-in.o, $(core-y))
libs-y := lib/
libs-y1 := $(patsubst %/, %/lib.a, $(libs-y))
libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y))
libs-y := $(libs-y1) $(libs-y2)
drivers-y := drivers/ sound/
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y))
net-y := net/
net-y := $(patsubst %/, %/built-in.o, $(net-y)) = net/built-in.o
vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE
vmlinux-init := $(head-y) $(init-y)
vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y)
vmlinux-all := $(vmlinux-init) $(vmlinux-main)
vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds
export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
架构目录Makefile：
zImage Image xipImage bootpImage uImage: vmlinux
head-y := arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
我已经把顶层目录和架构目录下生成vmlinux的命令摘选出来。首先，我们看要想生成vmlinux，需要vmlinux-lds文件、vmlinux-init文件、vmlinux-main文件。其中，vmlinux-lds是链接脚本文件，定义了代码段，数据段的存放位置。这里我们接着往下看，vmlinux-init需要head-y和init-y,通过查看两个Makefile，我们可以得到经过转换后的结果：
head-y :=
arch/arm/kernel/head$(MMUEXT).o arch/arm/kernel/init_task.o
init-y := $(patsubst %/, %/built-in.o, $(init-y)) = init/built-in.o
core-y := $(patsubst %/, %/built-in.o, $(core-y))
= usr/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o
libs-y := $(libs-y1) $(libs-y2) =lib/lib.a lib/built-in.o
drivers-y := $(patsubst %/, %/built-in.o, $(drivers-y)) = drivers/built-in.o sound/built-in.o
net-y := $(patsubst %/, %/built-in.o, $(net-y)) = net/built-in.o
现在已经分析了内核编译的全部过程。那怎样知道我们分析的到底对不对，通过实际执行make uImage我们就可以看到执行过程。这是执行make uImage过程中的部分相关命令：
arm-linux-ld -EL -p --no-undefined -X -o vmlinux
-T arch/arm/kernel/vmlinux.lds
arch/arm/kernel/head.o
arch/arm/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/arm/kernel/built-in.o arch/arm/mm/built-in.o
可以看到，首先目标要生成vmlinux，然后是链接脚本为vmlinux.lds。开始生成第一个文件：head.o，第二个文件：init_task.o。这和我们分析的完全一致。接下来以此类推，和我们分析的相同，也就是说我们分析的是正确的。
SECTIONS
{
. = (0xc0000000) + 0x00008000;
.text.head : {
_stext = .;
_sinittext = .;
*(.text.head)
}
.init : { /* Init code and data */
*(.init.text)
_einittext = .;
__proc_info_begin = .;
*(.proc.info.init)
__proc_info_end = .;
__arch_info_begin = .;
*(.arch.info.init)
__arch_info_end = .;
__tagtable_begin = .;
*(.taglist.init)
__tagtable_end = .;
. = ALIGN(16);
__setup_start = .;
*(.init.setup)
__setup_end = .;
__early_begin = .;
*(.early_param.init)
__early_end = .;
__initcall_start = .;
这是链接脚本vmlinux.lds中的部分内容。首先定义了虚拟地址:(0xc0000000) + 0x00008000。 然后是首先执行头部文件，这与我们分析的完全一致。代码段，初始化代码段等等。
这就是Linux内核的从配置到编译的全部分析了_
谈谈对Volatile关键字的理解
见之前C语言部分整理
framebuffer机制
Linux抽象出FrameBuffer这个设备来供用户态进程实现直接写屏。Framebuffer机制模仿显卡的功能，将显卡硬件结构抽象掉，可以通过Framebuffer的读写直接对显存进行操作。用户可以将Framebuffer看成是显示内存的一个映像，通过mmap将其映射到进程地址空间之后，就可以直接进行读写操作，而写操作可以立即反应在屏幕上。这种操作是抽象的，统一的。用户不必关心物理显存的位置、换页机制等等具体细节，这些都是由Framebuffer设备驱动来完成的。通过mmap调用把显卡的物理内存空间映射到用户空间。
spinlock与信号量的区别
见之前操作系统部分整理
linux中的同步机制
说出你所知道的各类linux系统的各类同步机制（重点），什么是死锁？如何避免死锁（每个技术面试官必问）
原子操作，不会被任何事务给打断，通常用于资源计数，引用计数。TCP/IP协议栈的IP碎片计数。
信号量。就像一个房间有好几把钥匙，拿到钥匙就能进去访问。设置为1的时候变为了mutex。绝大部分情况下作为互斥锁使用。
读写信号量。可以允许多个读，一个写。一旦有人在写，就大家都不能读。但是如果没人在写，就可以允许很多一起读。
自旋锁。自旋锁与互斥锁的区别在于不会导致睡眠，如果自旋锁被其他执行单元持有了，那么调用者就一直自旋在那循环地看持有者是否已经释放，而不睡眠。在持有时间短的情况下使用会比互斥锁高效。
顺序锁（seqlock）。读者可以在写的时候读，写者也可以在读的时候写，但是写与写之间还是互斥的。利用了一个序号，写的时候要对序号加1，这样读的人可以知道读的期间有没有人写。
什么是死锁及死锁的必要条件和解决方法
死锁。就是几个进程申请资源，出现了无限循环等待的现象。
四个必要条件
资源是互斥的
不可抢占
占有且申请
循环等待
解决方案也从这四个条件来着手
1. 资源的互斥是客观的，要改变的话不现实。
2. 申请资源不可满足的时候释放已经申请到的资源。
3. 只有在全部资源都可以得到的情况下才一次性分配。
4. 资源有序分配。给所有资源编号，进程对资源的请求必须是严格递增的序列，只有在占有了小号资源的情况下才能申请了大号资源。（假设打印机是小号资源，CDROM是大号资源）
自旋锁和信号量在互斥使用时需要注意哪些？在中断服务程序里面的互斥是使用自旋锁还是信号量？还是两者都能用？为什么？
使用自旋锁的进程不能睡眠,使用执行时间短的任务，使用信号量的进程可以睡眠，适合于执行时间较长的任务。中断服务例程中的互斥使用的是自旋锁，原因是在中断处理例程中，硬中断是关闭的，这样会丢失可能到来的中断。
驱动里面为什么要有并发、互斥的控制？如何实现？讲个例子？
并发（concurrency）指的是多个执行单元同时、并行被执行，而并发的执行单元对共 享资源（硬件资源和软件上的全局变量、静态变量等）的访问则很容易导致竞态（race conditions）。
解决竞态问题的途径是保证对共享资源的互斥访问，所谓互斥访问就是指一个执行单元 在访问共享资源的时候，其他的执行单元都被禁止访问。
访问共享资源的代码区域被称为临界区，临界区需要以某种互斥机 制加以保护，中断屏蔽，原子操作，自旋锁，和信号量都是linux设备驱动中可采用的互斥途径。
linux中断实现机制、tasklet和workqueue的区别和底层实现的区别，为什么要区分中断上半部和中断下半部
见之前Linux部分整理
中断和轮询哪个效率高？怎样决定是采用中断方式还是采用轮询方式去实现驱动？
中断是CPU处于被动状态下来接受设备的信号，而轮询是CPU主动去查询该设备是否有请求。凡事都是两面性，所以，看效率不能简单的说那个效率高。如果是请求设备是一个频繁请求cpu的设备，或者有大量数据请求的网络设备，那么轮询的效率是比中断高。如果是一般设备，并且该设备请求cpu的频率比较底，则用中断效率要高一些。主要是看请求频率。
写一个中断服务需要注意哪些？如果中断产生之后要做比较多的事情你是怎么做的？
第一： 中断处理例程应该尽量短，把能放在后半段(tasklet，等待队列等)的任务尽量放在后半段。
写一个中断服务程序要注意快进快出，在中断服务程序里面尽量快速采集信息，包括硬件信息，然后退出中断，要做其它事情可以使用工作队列或者tasklet方式。也就是中断上半部和下半部。
第二：中断服务程序中不能有阻塞操作。应为中断期间是完全占用CPU的（即不存在内核调度），中断被阻塞住，其他进程将无法操作；
第三：中断服务程序注意返回值，要用操作系统定义的宏做为返回值，而不是自己定义的OK，FAIL之类的。
IRQ和FIQ有什么区别，在CPU里面是是怎么做的？
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模式就没有那么多，R8,R9,R10,R11,R12对应的banked的寄存器就没有，这就意味着在ARM的IRQ模式下，中断处理程序自己要保存R8到R12这几个寄存器，然后退出中断处理时程序要恢复这几个寄存器，而FIQ模式由于这几个寄存器都有banked寄存器，模式切换时CPU自动保存这些值到banked寄存器，退出FIQ模式时自动恢复，所以这个过程FIQ比IRQ快.
FIQ比IRQ有更高优先级，如果FIQ和IRQ同时产生，那么FIQ先处理。
在symbian系统里，当CPU处于FIQ模式处理FIQ中断的过程中，预取指令异常，未定义指令异常，软件中断全被禁止，所有的中断被屏蔽。所以FIQ就会很快执行，不会被其他异常或者中断打断，所以它又比IRQ快了。而IRQ不一样，当ARM处理IRQ模式处理IRQ中断时，如果来了一个FIQ中断请求，那正在执行的IRQ中断处理程序会被抢断，ARM切换到FIQ模式去执行这个FIQ，所以FIQ比IRQ快多了。
另外FIQ的入口地址是0x1c,IRQ的入口地址是0x18。
Linux软中断和工作队列的作用是什么
见之前Linux部分
