因为没有库连接到模块中, 源文件不应当包含通常的头文件, <stdarg.h>和非常特殊的情况是仅有的
例外. 只有实际上是内核的一部分的函数才可以在内核模块里使用. 内核相关的任何东西都在头文
件里声明, 这些头文件在你已建立和配置的内核源码树里; 大部分相关的头文件位于 include/linux
和 include/asm, 但是别的 include 的子目录已经添加到关联特定内核子系统的材料里了。
另外一个在内核编程和应用程序编程之间的重要不同是每一个环境是如何处理错误: 在应用程序
开发中段错误是无害的, 一个调试器常常用来追踪错误到源码中的问题, 而一个内核错误即使不终止整个系统，
至少会杀掉当前进程. 。。。原文翻译得不通顺
无论何时一个应用程序发出一个系统调用或者被硬件中断
挂起时. 执行系统调用的内核代码在进程的上下文中工作 -- 它代表调用进程并且可以存取该进程
的地址空间. 换句话说, 处理中断的代码对进程来说是异步的, 不和任何特别的进程有关.---????
***********************************************************************
内核代码不
能(极少)假定它能在一段给定代码上持有处理器. 如果你不考虑并发来编写你的代码, 就极有可能*******一定要考虑程序的并发性
导致严重失效, 以至于非常难于调试.
*****************************************************************
内核代码可以引用当前进程, 通过存取全局项 current, 它在 <asm/current.h> 中定义, 它产生一个指针指向结
构 task_struct, 在 <linux/sched.h> 定义. current 指针指向当前在运行的进程. 在一个系统调用执行期
间, 例如 open 或者 read, 当前进程是发出调用的进程. 内核代码可以通过使用 current 来使用进程特
定的信息, 如果它需要这样.
实际上, current 不真正地是一个全局变量. 支持 SMP 系统的需要强迫内核开发者去开发一种机制,
在相关的 CPU 上来找到当前进程. 这种机制也必须快速, 因为对 current 的引用非常频繁地发生. 结
果就是一个依赖体系的机制, 常常, 隐藏了一个指向 task_struct 的指针在内核堆栈内. 实现的细节对
别的内核子系统保持隐藏, 一个设备驱动可以只包含 <linux/sched.h> 并且引用当前进程. 例如, 下面
的语句打印了当前进程的进程 ID 和命令名称, 通过存取结构 task_struct 中的某些字段.
printk(KERN_INFO "The process is \"%s\" (pid %i)\n", current->comm, current->pid);
存于 current->comm 的命令名称是由当前进程执行的程序文件的基本名称( 截短到 15 个字符, 如果
需要 ).