內(nèi)核頭文件傳奇

dj_ukyo

內(nèi)核頭文件傳奇
http://www.linuxsir.org/bbs/thread303531-2.html
做 LFS 是不是很累了？OK，讓我先來講一段八卦故事，放松放松神經(jīng)，然后再繼續(xù)冒險吧。。。
在 Linux 2.2/2.4 的純真年代，內(nèi)核頭文件一直保持著 Unix 世界的"KISS"傳統(tǒng)，只需將內(nèi)核源碼樹中的頭文件直接復(fù)制到 /usr/include 中即可使用，一切都是那么 Simple and Stupid ...
但是隨著 2.6 系列內(nèi)核的發(fā)布，事情開始變得混亂和復(fù)雜起來。首先是內(nèi)核開發(fā)者宣布強(qiáng)烈反對直接使用"未凈化"的"原始"內(nèi)核頭文件，他們建議使用發(fā)行版提供的"經(jīng)過凈化的"內(nèi)核頭文件。于是各種發(fā)行版開始"八仙過海，各顯神通"，由于"凈化"方法各不相同，結(jié)果就是每個發(fā)行版都有著自己與眾不同的內(nèi)核頭文件。更為嚴(yán)重的是，內(nèi)核開發(fā)者甚至推薦編譯 Glibc 的頭文件也要使用發(fā)行版提供的"經(jīng)過凈化的"內(nèi)核頭文件。由于 Glibc 和 Kernel 是整個系統(tǒng)的根基，這樣一來 Linux 便像傳統(tǒng)的 Unix 那樣開始走向分裂。
另一件哭笑不得的事情是，雖然內(nèi)核開發(fā)者強(qiáng)烈推薦使用發(fā)行版提供的"經(jīng)過凈化的"內(nèi)核頭文件，但是 Glibc 的開發(fā)者卻不買賬，他們推薦使用"未凈化"的"原始"內(nèi)核頭文件來編譯 Glibc ，兩個開發(fā)組一直堅持各自的見解，互不妥協(xié)！另外，兩個開發(fā)組在應(yīng)當(dāng)由誰提供內(nèi)核頭文件的問題上意見也不一致：內(nèi)核開發(fā)組認(rèn)為應(yīng)當(dāng)由發(fā)行版的制作者提供，而 Glibc 開發(fā)組認(rèn)為應(yīng)當(dāng)由內(nèi)核開發(fā)組提供。結(jié)果就是"神仙打架，凡人遭殃"，雖然對 Debian 這種大型發(fā)行版來說，提供自己獨(dú)有的"經(jīng)過凈化的"內(nèi)核頭文件不會成為多大的負(fù)擔(dān)，但是對于那些沒有能力或精力的小心發(fā)行版制作者和我們這些 DIY fans 來說卻是一場災(zāi)難！要么直接使用其他發(fā)行版的成果，要么自力更生；前者讓人心有不甘(沒有了 DIY 的原汁原味)，后者讓人望而生畏(有幾個人知道啥叫"凈化"?怎么凈化?)。
危機(jī)時刻總會有英雄的出現(xiàn)，就在一片恐慌之際，一個叫"linux-libc-headers"項目組誕生了！他們向我們這些"凡人"們提供了安全的、普遍適用的、"經(jīng)過凈化的"內(nèi)核頭文件，真是及時雨啊！天空重新晴空萬里……然而好景不長，由于精力和人力有限，該項目在發(fā)布了 2.6.12.0 版本之后，遺憾的離開了這個世界。這樣一來，2.6.12 以上版本的內(nèi)核新特性(比如新的系統(tǒng)調(diào)用)和 ABI/API 的變化就無法反映出來，對于我們這些 DIY fans 來說，世界重回混沌……
俗話說，"合久必分，分久必合"，大概是內(nèi)核開發(fā)組意識到了如果繼續(xù)固執(zhí)己見將不可避免的導(dǎo)致混亂以及重蹈 Unix 逐漸走向分裂的覆轍，于是從 2.6.18 版本開始，內(nèi)核開發(fā)組擔(dān)負(fù)起了維護(hù)一份統(tǒng)一的、"經(jīng)過凈化的"內(nèi)核頭文件的職責(zé)(竊以為這原本就是他們的責(zé)任)�，F(xiàn)在獲取"經(jīng)過凈化的"內(nèi)核頭文件又變得簡單起來，只要在內(nèi)核源碼樹中使用 make headers_install 即可，而且不用再擔(dān)心更新問題。對于我們這些 DIY fans 來說，又可以重新 Day Day Happy 了。
不過，由于磨合需要時間。目前 Glibc-2.4 以下的版本都無法配合這種新式頭文件編譯成功。不過偶相信前途一片光明……
               
               
               

本文來自ChinaUnix博客，如果查看原文請點：http://blog.chinaunix.net/u/7793/showart_1797311.html