写业务代码，可能每天大部分时间调别人的接口，接口不合适封装个函数，需求也不断变动。
总归实现功能最重要，用户体验最重要，别人提需求，你只管实现。
你就像无情的机器，写重复的业务代码，实现相似的功能，感觉没长进，眼界也没提升......
但驱动开发截然不同......
行不行，你说了算
业务代码，最多的就是需求变动。
例如，这个模块再加个功能，这个代码再封装一下，你这样写不行要这样写......
但是，对于一个驱动来说，它能用就是能用，不能用就是不能用，没有太多的需求可言。
例如一个网卡驱动，它能正常连接网络，能正常传输文件就是它的功能，代码怎么写是根据芯片手册来的，没人会对你提什么需求。
所以，没有需求的烦恼。只要能用，你的任务就完成了，不会有什么需求过来，最多就是改一下bug。
为什么不敢动？
驱动代码不像应用层写的业务逻辑，业务代码可能更多的是一些编程技巧、代码优化上的东西，例如接口封装、参数判断、特殊情况处理等一些偏软件设计上的东西，如果看到某段业务逻辑写的不好，有些经验的人都是比较容易去改你的代码的。
但写驱动代码有一个最大特点，就是先把芯片手册看懂。
例如驱动里分配了一个64字节对齐的内存、调度前又设置了一遍寄存器，为什么要这么做？你是不知道的。
如果别人觉得你的驱动有问题，想改你的代码，那他应该先把芯片手册看懂。
没看过芯片手册之前，这个代码他没法动，这个名词、这个比特位是什么意思，代码为什么这么写，只有你才知道。
即便是驱动真有问题，也一定是你自己改，因为一般人不会闲着没事去看不属于他工作范围的文档，况且把文档看懂都要好几天。
即便是一处很小的错误，通常也是你自己改，因为别人不知道改了这个地方，会不会影响其他地方，只有写这个驱动的人才知道。
所以只要驱动能正常用，就不太会有人去动它了。
如果是业务代码，通常都是需求牵着你走，一切为了用户体验。
但驱动代码相反，我只会告诉你，我有什么功能，而不是你来告诉我，你要什么功能。
一个驱动，它的功能就只有这些，只能少不能多，我可以告诉你这个驱动有这些功能，你想要什么样的接口，我可以提供ioctl接口或者其他接口给你调用。
如果你说你要传一个参数，把xxx返回给你，我也有可能跟你说，做不到。如果你说你要同时传一些参数，把xxx同时返回，我也只会告诉你做不到。
你问为什么？因为这个硬件本身就做不到这样的效果。如果你不信，那你去把芯片手册看一遍吧，看懂再来问我。