0 前言

大家都知道，内核开发跟应用开发，体验是完全不同的，尤其是驱动。一方面要掌握扎实的语言基础，另一方面还要对操作系统的基本概念深入理解。然后配合软硬件的一些知识，才能做好驱动的开发任务。

博主最近做一个虚拟设备驱动，再次体验到了什么叫纸上得来终觉浅，绝知此事要躬行。

现实中，大部分开发人员（包括博主本人）都是应用开发者，无论是做产品还是项目，主要都是面向特定的业务。而内核，毕竟是一个通用系统，很多情况下是拿来就用，开箱就用。专门做内核开发的人员还是少数。这其中的大部分，也都是主要做驱动开发的。内核开发者主要分布在芯片厂商、互联网大厂以及爱好者社区这三类地方。芯片厂商面对的主要是移植、驱动，互联网大厂面对的主要是优化，而爱好者，可能二者兼具了。

当然，对于做终端产品的厂家，内核开发也是需要的，但是不同的一点是，往往一个产品的初期，内核部分的工作有一些，系统和硬件定型稳定后，主要工作还是应用空间的业务代码编写。所以，有的公司，这两类工作就是一类人干的。初期干内核，写驱动，调移植，后期做应用。此时，为了上手内核开发，入门办法就是买本书学，边学边做。在计算机编程领域，这也没有什么问题，因为写代码本来就是一门实践技能。但问题就在于，如果学了不用，那么就会似懂非懂。即便是应用层开发也是这样，更不要说内核空间了。所以，一个合格的内核开发人员，所需要的培养周期往往就比较长。

这个引子说的有点离题了。主要是啥意思呢，就是想表达博主也是看过不少内核开发书籍的，结果在开发虚拟设备驱动的过程中，遇到了几个活学活用的问题，让我对“纸上”和“躬行”有了更加切身和深刻的体会，于是在这里记录分享，也希望能对从事这方面工作的读者有所帮助。

先大概说一下需求：内核虚拟驱动需要周期性（高频）采集硬件数据，满足一个块后，将其拷贝到用户空间。大概就是这样一个功能。就是这样简单的功能，实际开发中遇到了几个印象深刻的问题。

1 ioremap、vmalloc与原子上下文

最开始在驱动初始化和open系统调用下来的接口中使用上述接口。后来因为架构调整，将数据映射放到了定时器接口中，结果出现异常。后来思考，ioremap、vmalloc这类的接口，可能会导致睡眠，而内核定时器是在定时中断和软中断的上下文，属于原子上下文，所以不能在定时器中使用上述接口。另外，也不能在定时器接口中使用mutex等锁接口。如果有内存分配需求，则需要GFP_ATOMIC标识，如果需要同步，则需要使用spin_lock自旋锁。

一般大家在中断处理函数中会特别注意这些事项，定时器可能遇到的少，但是一旦有类似需求，就要跟中断一样，按照原子上下文要求来使用。

2 copy_to_user与进程上下文

同上面类似，开始是在系统调用的对接接口中使用上述接口，将数据拷贝到用户空间，没有问题。后来，因为频率控制需求，将其移动到了定时器中，结果内核直接奔溃。想到是原子上下文导致，就重新创建一个内核线程，将其移动到内核线程。此时虽然没有奔溃了，但是拷贝数据不成功。反复测试都是这样。准备调试到copy_to_user内部，看看在哪里出问题了，就在此时，脑海中浮现了答案：内核线程没有用户空间，自然copy_to_user就无用武之地。在感叹内核里面处处是陷阱的同时，也不得不感叹，以前写代码只是浮于表面的了解，没有深入理解和掌握，更没有做到活学活用。好在及时想到，不算浪费太多时间。

另外需要注意copy_to_user的返回值，返回0表示成功，返回具体数值，则表示未成功拷贝的字节数，这与大部分接口设计的返回值是不同的。所以千万不能惯性思维，以免出现错误。

3 fasync与指针初始化

驱动里有关需求，就是在内核完成任务后，需要通过信号异步通知应用。这个需求通过下面的代码来实现：

if (dev->fasync) {

kill_fasync(&dev->fasync, SIGIO, POLL_IN);

}

但是，每次跑到这里就触发异常。反复跟踪调试发现，这里的fasync域是一个指针：struct fasync_struct *fasync;，在调用fasync_helper(fd, filp, mode, &dev->fasync);赋值之前，是没有值的，但是如果我们分配dev内存之后不初始化的话，fasync域可能是一个随机值，这样再判断指针时，就会误判，从而调用kill_fasync，触发异常。这倒不算一个大问题，主要是保持良好的编码习惯，指针变量定义后，给初值，就会避免此类问题。

4 wait_event_interruptible与条件变量

为了让进程睡眠挂起，驱动中使用了上述接口。对应的，唤醒接口为wake_up_interruptible。一般的使用方式时，在内核线程或者系统调用中，使用标题中的接口让进程睡眠，然后在中断或者定时器等判断触发条件的处理中，在条件满足是，使用唤醒接口，让进程重新起来工作。但是，实际测试中发现，调用唤醒后，进程始终未被唤醒。反复检查代码，发现是接口中变量的作用域导致。除非使用全局变量，否则中断或者定时器与进程上下文并不共享内存空间，如果条件变量不为真，wait_event_interruptible是不会退出的。如果你在调试代码中遇到了奇怪的问题，特别是非常肯定代码逻辑正常，但是效果不符合预期，反复检查都没有答案的时候，而且就要怀疑机器是不是有问题的时候，就需要考虑这些因素：拼写是否有误、中英文是否没有区分、文件字符编码是否不对、是不是打开了输入法的全角、是否用错了斜杆方向、单引号双引号使用不对等等。只要坚信机器是没有问题的，问题都在我的身上，那么上述问题都是可以找到的。否则，谁都无法保证会发生什么。