1，字符型驱动设备是怎么创建设备文件的，就是/dev/下面的设备文件，供上层应用程序打开使用的文件？
答：方式一（手动）：mknod命令结合设备的主设备号和次设备号，可创建一个设备文件；
方式二（自动）：UDEV/MDEV自动创建设备文件的方式，UDEV/MDEV是运行在用户态的程序，可以动态管理设备文件，包括创建和删除设备文件，运行在用户态意味着系统要运行之后；
方式三（自动）：在系统启动期间还有devfs创建了设备文件。
2，写一个中断服务需要注意哪些？如果中断产生之后要做比较多的事情你是怎么做的？
答：(1)中断处理例程应该尽量短，注意快进快出，在中断服务程序里面尽量快速采集信息，包括硬件信息，然后推出中断，要做其它事情可以使用工作队列或者tasklet方式。也就是中断上半部和下半部；
(2)中断服务程序中不能有阻塞操作；
(3)中断服务程序注意返回值，要用操作系统定义的宏做为返回值，而不是自己定义的FAIL，OK，之类的。
中断服务程序（ISR，Interrupt Service Routines）：处理器处理"急件"，可理解为是一种服务，是通过执行事先编好的某个特定的程序来完成的。
3，自旋锁和信号量在互斥使用时需要注意哪些？在中断服务程序里面的互斥是使用自旋锁还是信号量？还是两者都能用？为什么？
答：使用自旋锁的进程不能睡眠，使用信号量的进程可以睡眠。中断服务例程中的互斥使用的是自旋锁，原因是在中断处理例程中，硬中断是关闭的，这样会丢失可能到来的中断。
自旋锁：它是为实现保护共享资源而提出一种锁机制。其实，自旋锁与互斥锁比较类似，它们都是为了解决对某项资源的互斥使用。无论是互斥锁，还是自旋锁，在任何时刻，最多只能有一个保持者，也就说，在任何时刻最多只能有一个执行单元获得锁。但是两者在调度机制上略有不同。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。但是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，"自旋"一词就是因此而得名。
信号量：有时被称为信号灯，是在多线程环境下使用的一种设施，是可以用来保证两个或多个关键代码段不被并发调用。在进入一个关键代码段之前，线程必须获取一个信号量;一旦该关键代码段完成了，那么该线程必须释放信号量。其它想进入该关键代码段的线程必须等待直到第一个线程释放信号量。为了完成这个过程，需要创建一个信号量VI，然后将Acquire Semaphore VI以及Release Semaphore VI分别放置在每个关键代码段的首末端。确认这些信号量VI引用的是初始创建的信号量。
互斥锁：在多线程开发中，我们采用@synchronized来创建一个互斥锁，保证在同一时刻只有一个线程对其进行操作。
4，原子操作你怎么理解？
答：原子操作，即不可分割开的操作，该操作一定是在同一个cpu时间片中完成，这样即使线程被切换，多个线程也不会看到同一块内存中不完整的数据。如果这个操作所处的层(layer)的更高层不能发现其内部实现与结构，那么这个操作是一个原子(atomic)操作。原子操作可以是一个步骤，也可以是多个操作步骤，但是其顺序不可以被打乱，也不可以被切割而只执行其中的一部分。将整个操作视作一个整体是原子性的核心特征。
5，nsmod 一个驱动模块，会执行模块中的哪个函数？rmmod呢？这两个函数在设计上要注意哪些？遇到过卸载驱动出现异常没？是什么问题引起的？
答：insmod调用init函数，rmmod调用exit函数。
卸载模块时曾出现卸载失败的情形，原因是存在进程正在使用模块，检查代码后发现产生了死锁的问题。
要注意在init函数中申请的资源在exit函数中要释放，包括存储，ioremap，定时器，工作队列等等。也就是一个模块注册进内核，退出内核时要清理所带来的影响，带走一切不留下一点痕迹。
6，在驱动调试过程中遇到过oops没？你是怎么处理的？
答：什么是Oops？从语言学的角度说，Oops应该是一个拟声词。当出了点小事故，或者做了比较尴尬的事之后，你可以说"Oops"，翻译成中国话就叫做“哎呦”。“哎呦，对不起，对不起，我真不是故意打碎您的杯子的”。看，Oops就是这个意思。
在Linux内核开发中的Oops是什么呢？其实，它和上面的解释也没什么本质的差别，只不过说话的主角变成了Linux。当某些比较致命的问题出现时，我们的Linux内核也会抱歉的对我们说：“哎呦（Oops），对不起，我把事情搞砸了”。Linux内核在发生kernel panic时会打印出Oops信息，把目前的寄存器状态、堆栈内容、以及完整的Call trace都show给我们看，这样就可以帮助我们定位错误。
