2.和硬件接口以及和用户态的接口
从硬件那里接收信息，这个用中断实现，和硬件互相读写，这个用基本IO实现；从用户接收请求，这个用系统调用...向用户发送信息，这个用信号...。无疑，这样就在接口层次满足了上层用户和底层硬件的要求，无疑，UNIX在这一点上是成功的(信号，IPC，POSIX...)。
二.大内核和微内核
如果我们把操作系统内核在其生命周期的前期按照时间分割，我们把它分为源码阶段和二进制阶段，大内核和微内核的区分是二进制阶段的区分。我们都知道，Linux是大内核，然而为何大而不乱呢？实际上看看它的源码就明白了，它的源码组织非常好，核心文件不到100个，其它的都是驱动或者体系结构相关的代码。毕竟，开发者知道，对于二进制文件，人是看不懂的，人所看的是源码，将二进制文件分开，无疑会增加维护的复杂性，更何况，将问题控制在源码阶段就节省了很多调试时间。
三.设备驱动开发
1.阅读datasheet，编写IO、中断例程
2.和操作系统内核接口，也就是插入内核最低端
3.和用户态接口，也就是在最上端导出一个用户接口，比如ioctl
4.编写用户态demo和工具进程，调用第3步的接口
5.试用，调试打包
6.总结，层次结构-从上到下：最终用户-应用程序员-系统程序员-驱动程序员-硬件工程师
四.到底应不应该在内核中解决fork炸弹
fork炸弹臭名昭著，一堆看似乱码的字符就能耗尽你的cpu：.(){.|.&};.。如果想在内核解决它，那是很简单的，那就是控制task_struct的层数，我们知道Linux进程是分层树形组织的，如果限制层数最多为5层，那么该炸弹最多也就是炸五次就无法发挥作用了，然而这却不是好方法，因为这会损害那些正好需要6层或以上的正常程序的利益。其实还有很多解决办法：1.利用cpu组调度，限制它们可以使用的资源；2.修改oom killer的核心算法，优先砍掉那些过于长，然而却很瘦的树枝，这也符合园艺工人的操作方式，因为这种枝丫会带走过多的养分！