Beyond the Void
BYVoid
Linux內核與glibc
本文正體字版由OpenCC轉換

轉自[Fedora 中文郵件列表] 作者microcai@fedoraproject.org

往往內核添加了一個功能, glibc 要花很久纔會用上。本來linux 那邊爲這個功能是否進入內核已經吵半天了,glibc這邊又要爲是否使用這個內核新特性再次吵架半天 (glibc 不是 Linux 專有的,還得考慮 BSD (雖然人家也不用 glibc),SysV Windows(誒,這沒辦法),還有 sun 那消亡的 solaris , 還有, 自家的 Hurd。然後,總之,這樣新特性讓人的接受上。。。 太慢了。

說近點的,fnotify glibc還沒有對應的包裝函數呢,futex 和 NPTL 又是花了許久才進入主流的。libc 是 app和內核的橋樑,libc 理應快速跟上內核的接口變化。但是 glibc 和內核不是一塊開發的,所以,這只是理想罷了。glibc 還要去兼容不同版本的內核呢!

而內核也要去兼容不同版本的 glibc . 雙方都揹負了太多的歷史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老內核。Linux對已經沒用,甚至有bug(接口的問題導致一些bug是必須的)的系統調用也必須保留,誰知道用戶會用哪個版本的glibc呢?雖然新的glibc會使用新的調用,但是提供和老的調用一致的 API 來兼容,但是,用戶只升級內核而不升級 glibc 是常有的事情。就算升級了glibc ,你新版本的 glibc 一定就用上內核的新接口?還是再等幾年等 glibc 的開發者吵架結束吧。

於是乎,Linux 的大牛們再次使出絕招: 讓 libc 變成 VDSO 進駐內核。 這裏普及一下 VDSO 這個小知識,知道的人跳過,不知道的人讀一下 VDSO 就是 Virtual Dynamic Shared Object ,就是內核提供的虛擬的 .so , 這個 .so 文件不在磁盤上,而是在內核裏頭。 內核把包含某 .so 的內存頁在程序啓動的時候映射入其內存空間,對應的程序就可以當普通的 .so 來使用裏頭的函數。比如 syscall() 這個函數就是在 linux-vdso.so.1 裏頭的,但是磁盤上並沒有對應的文件. 可以通過 ldd /bin/bash 看看

這樣,隨內核發行的 libc 就唯一的和一個特定版本的內核綁定到一起了。注意,VDSO只是隨內核發行,沒有在內核空間運行,這個不會導致內核膨脹。這樣內核和libc都不需要爲兼容多個不同版本的對方而寫太多的代碼,引入太多的 bug 了。

當然, libc 不單單有到內核的接口,還有很多常用的函數,這些函數不需要特別的爲不同版本的內核小心編寫,所以,我估計Linux上會出現兩個 libc , 一個 libc 在內核,只是系統調用的包裹,另一個libc 還是普通的 libc ,只是這個 libc 再也不需要花精力去配合如此繁多的 kernel 了。

姑且一個叫kernellibc, 一個叫 glibc : printf() 這些的還在 glibc。open() , read() , write(), socket() 這些卻不再是 glibc 的了,他們在kernellibc。


上次修改時間 2017-05-22

相關日誌