llinux系统头文件、C标准库头文件简介

头文件概述：

在进行有关系统软件的安装的时候（编译一个新的驱动，或者安装一个系统级别的测试工具，例如systemtap），经常需要重新编译内核，相应的问题往往与内核头文件有关。那么，什么是内核头文件，为什么需要更新内核头文件？内核头文件作用是什么，如何更新？本文主要为你解答这些疑问。

在 Linux 2.2/2.4 的纯真年代，内核头文件一直保持着 Unix 世界的"KISS"传统，只需将内核源码树中的头文件直接复制到 /usr/include 中即可使用，一切都是那么 Simple and Stupid ...

        但  是随着 2.6 系列内核的发布，事情开始变得混乱和复杂起来。首先是内核开发者宣布强烈反对直接使用"未净化"的"原始"内核头文件，他们建议使用发行版提供的"经过净化的"内核头文件。于是各种发行版开始"八仙过海，各显神通"，由于"净化"方法各不相同，结果就是每个发行版都有着自己与众不同的内核头文件。更为严重的是，内核开发者甚至推荐编译 Glibc 的头文件也要使用发行版提供的"经过净化的"内核头文件。由于 Glibc 和 Kernel 是整个系统的根基，这样一来 Linux 便像传统的 Unix 那样开始走向分裂。
        另一件哭笑不得的事情是，虽然内核开发者强烈推荐使用发行版提供的"经过净化的"内核头文件，但是 Glibc 的开发者却不买账，他们推荐使用"未净化"的"原始"内核头文件来编译 Glibc ，两个开发组一直坚持各自的见解，互不妥协！另外，两个开发组在应当由谁提供内核头文件的问题上意见也不一致：内核开发组认为应当由发行版的制作者提供，而 Glibc 开发组认为应当由内核开发组提供。结果就是"神仙打架，凡人遭殃"，虽然对 Debian 这种大型发行版来说，提供自己独有的"经过净化的"内核头文件不会成为多大的负担，但是对于那些没有能力或精力的小心发行版制作者和我们这些 DIY fans 来说却是一场灾难！要么直接使用其他发行版的成果，要么自力更生；前者让人心有不甘(没有了 DIY 的原汁原味)，后者让人望而生畏(有几个人知道啥叫"净化"?怎么净化?)。
        危机时刻总会有英雄的出现，就在一片恐慌之际，一个叫"linux-libc-headers"项目组诞生了！他们向我们这些"凡人"们提供了安全的、普遍适用的、"经过净化的"内核头文件，真是及时雨啊！天空重新晴空万里……然而好景不长，由于精力和人力有限，该项目在发布了 2.6.12.0 版本之后，遗憾的离开了这个世界。这样一来，2.6.12 以上版本的内核新特性(比如新的系统调用)和 ABI/API 的变化就无法反映出来，对于我们这些 DIY fans 来说，世界重回混沌……
        俗话说，"合久必分，分久必合"，大概是内核开发组意识到了如果继续固执己见将不可避免的导致混乱以及重蹈 Unix 逐渐走向分裂的覆辙，于是从 2.6.18 版本开始，内核开发组担负起了维护一份统一的、"经过净化的"内核头文件的职责(窃以为这原本就是他们的责任)。现在获取"经过净化的"内核头文件又变得简单起来，只要在内核源码树中使用 make headers_install 即可，而且不用再担心更新问题。对于我们这些 DIY fans 来说，又可以重新 Day Day Happy 了。

        不过，由于磨合需要时间。目前 Glibc-2.4 以下的版本都无法配合这种新式头文件编译成功。

2内核头文件的作用

        说了这么多,那么什么时候会用到内核头文件呢？内核头文件又有哪些与用户有关的作用呢？

        概括来说，内核头文件的作用主要有两个：

       1）定义内核组件间的接口

        2）定义内核与用户空间的接口

       内部模块：模块间的内部接口在linux/include/ 或 linux/arch/*/include/ 下都有定义。一个单独模块的源文件间的接口应该同模块源码置于同一目录下，避免污染全局头文件空间。

    外部模块：传统的内核源码安装在/usr/src/linux下，这不再支持外部模块的编译。相反，你的Makefile应该指向/lib/modules/${kver}/build，其中${kver}是内核确切的版本字符串，例如：对于当前正在运行的内核，就是“uname -r”的输出。

        用户空间程序：一般来说，用户空间程序是针对发行版提供的头文件编译的，通常源于glibc-devel、glibc-kernheaders 或 linux-libc-dev。这些头文件通常来源于旧版内核，并不能安全地在不重新编译glibc的情况下被替换。特别地，作为一个到/usr/src/linux/include或/lib/modules/*/build/include/linux的符号链接/usr/include/linux，是极不推荐使用的。因为它经常使重新编译的应用程序损坏。例如，旧内核使用include/asm-${arch}存放架构特定的头文件，而不是现在的arch/${arch}/include/asm ，且没有符号链接到架构特定的目录。

3.如何打包头文件

        为发行版打包头文件：为一个发行版打包头文件正确的方法是在内核源码目录下运行 'make headers_install'来安装头文件到/usr/include，并依赖这个刚刚安装的特定版本的内核头文件重新编译C库包。如果你正在发布一个依赖某个特定版本内核头文件的用户空间程序，比如因为你的程序只运行在打过补丁或者最新的内核上，你不能依赖/usr/include中的头文件。你也不能使用来自/usr/src/linux/include 或/lib/modules/*/build/include/的头文件，因为他们还没有为用户空间的包含做好准备。若你尝试这么做了，内核会警告你并指引你到这个Wiki页。解决这个问题的正确方法是独立出你需要的特定接口，比如一个打过补丁的新内核并为你的应用程序提供字符设备ioctl号的独立头文件。在你自己的程序中添加一份这个源文件的拷贝，并说明这个应该和新内核版本保持一致。如果你的程序不遵循GPLv2证书，请保证你得到了这个文件作者的许可：可在你自己程序的证书下发布它。因为你的程序现在依赖的内核接口并不在常规内核中。在这种情况下，一个推荐的做法是通过运行时检测来保证内核知道这个接口并在无法向下兼容旧接口的时候给出有用的错误信息。

1. 1、在内核源码根目录下运行： 'make headers_install'，这样内核Makefile会把提供给应用程序的头文件提取并放在内核源码的“usr/include”目录下。
2. （请勿担心git会发现文件增加了，usr目录中的.gitignore文件已经让git忽略了其下的include文件夹）
3. 
   
4. 2、在编译应用程序的时候，在GCC的CFLAG参数中添加“-I(内核源码路径)/usr/include”，这样编译器就知道在编译时找到相关的头文件了。

关于这个头文件的问题，其实是有一段历史故事的： 《内核头文件传奇》。挺有意思的，大家看过后就知道内核头文件的使用为什么是这样了。

 

参考：

1、http://t3.qpic.cn/mblogpic/d679e6e39b9a87477c7e/2000

2、linux 文档Documentation / make / headers_install.txt

3、Documentation/kbuild/makefiles.txt

 

要想导出头文件到指定目录，可以使用如下命令：

 

make headers_install ARCH=arm INSTALL_HDR_PATH=/usr/include

其中ARCH指定要产生哪种体系结构的头文件，INSTALL_HDR_PATH指定要导出头文件的目录。

 

如果只是执行make headers_install ，则导出所有体系结构的头文件到默认目录"./usr/include。

如果是自己定义的头文件，要想导出，需要修改头文件下的Kbuild文件，例如我们自己定义的头文件在include/linux/generic/目录下

有如下头文件：

gsm.h, sensor.h

 

需要修改Kbuild文件：

header-y += gsm.h

header-y += sensor.h

如果是目录的话，添加

header-y += file/

1Linux内核所在目录为/usr/src/kernels/...

2Linux头文件所在目录为/usr/include/...

头文件目录中总共有32个.h头文件。其中主目录下有13个，asm子目录中有4个，linux子目录中有10个，sys子目录中有5个。这些头文件各自的功能如下，具体的作用和所包含的信息请参见第14章。
    <a.out.h>：a.out头文件，定义了a.out执行文件格式和一些宏。
<const.h>：常数符号头文件，目前仅定义了i节点中i_mode字段的各标志位。
<ctype.h>：字符类型头文件，定义了一些有关字符类型判断和转换的宏。
<errno.h>：错误号头文件，包含系统中各种出错号。(Linus从minix中引进的)。
<fcntl.h>：文件控制头文件，用于文件及其描述符的操作控制常数符号的定义。
<signal.h>：信号头文件，定义信号符号常量，信号结构以及信号操作函数原型。
<stdarg.h>：标准参数头文件，以宏的形式定义变量参数列表。主要说明了一个类型（va_list）和3个宏（va_start, va_arg和va_end），用于vsprintf、vprintf、vfprintf函数。
<stddef.h>：标准定义头文件，定义了NULL, offsetof(TYPE, MEMBER)。
<string.h>：字符串头文件，主要定义了一些有关字符串操作的嵌入函数。
<termios.h>：终端输入输出函数头文件，主要定义控制异步通信口的终端接口。
<time.h>：时间类型头文件，主要定义了tm结构和一些有关时间的函数原形。
<unistd.h>：Linux标准头文件，定义了各种符号常数和类型，并声明了各种函数。如，定义了__LIBRARY__，则还包括系统调用号和内嵌汇编_syscall0()等。
<utime.h>：用户时间头文件，定义了访问和修改时间结构以及utime()原型。
   （1）体系结构相关头文件子目录include/asm
    这些头文件主要定义了一些与CPU体系结构密切相关的数据结构、宏函数和变量。共4个文件。
    <asm/io.h>：I/O头文件，以宏的嵌入汇编程序形式定义对I/O端口操作的函数。
<asm/memory.h>：内存拷贝头文件，含有memcpy()嵌入式汇编宏函数。
<asm/segment.h>：段操作头文件，定义了有关段寄存器操作的嵌入式汇编函数。
<asm/system.h>：系统头文件，定义了设置或修改描述符/中断门等的嵌入式汇编宏。
  （2）Linux内核专用头文件子目录include/linux
    <linux/config.h>：内核配置头文件，定义键盘语言和硬盘类型（HD_TYPE）可选项。
<linux/fdreg.h>：软驱头文件，含有软盘控制器参数的一些定义。
<linux/fs.h>：文件系统头文件，定义文件表结构（file,buffer_head,m_inode等）。
<linux/hdreg.h>：硬盘参数头文件，定义访问硬盘寄存器端口、状态码和分区表等信息。
<linux/head.h>：head头文件，定义了段描述符的简单结构，和几个选择符常量。
<linux/kernel.h>：内核头文件，含有一些内核常用函数的原形定义。
<linux/mm.h>：内存管理头文件，含有页面大小定义和一些页面释放函数原型。
<linux/sched.h>：调度程序头文件，定义了任务结构task_struct、初始任务0的数据，
    以及一些有关描述符参数设置和获取的嵌入式汇编函数宏语句。
<linux/sys.h>：系统调用头文件，含有72个系统调用C函数处理程序,以"sys_"开头。
<linux/tty.h>：tty头文件，定义了有关tty_io，串行通信方面的参数、常数。
  （3）系统专用数据结构子目录include/sys
   <sys/stat.h>：文件状态头文件，含有文件或文件系统状态结构stat{}和常量。
<sys/times.h>：定义了进程中运行时间结构tms以及times()函数原型。
<sys/types.h>：类型头文件，定义了基本的系统数据类型。
<sys/utsname.h>：系统名称结构头文件。

<sys/wait.h>：等待调用头文件，定义系统调用wait()和waitpid()及相关常数符号。

ref:http://blog.sina.com.cn/s/blog_880a802e0100v93n.html