轉自[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。