這段時間看Linux內核源碼的時候，經常碰到vdso這個東西(像在Feature-fixup中，獲取時間等操作時)，網上搜了一下，才知道了含義，原來這是Linux為了解決和glibc兼容而想出的絕招啊。下面是從Fedora中文郵件列表轉過來的，和大家分享一下。
往往內核添加了一個功能，glibc要花很久才會用上。本來linux那邊為這個功能是否進入內核已經吵半天了，glibc這邊又要為是否使用這個內核新特性再次吵架半天(glibc不是Linux專有的，還得考慮BSD(雖然人家也不用glibc)，SysV Windows(诶，這沒辦法)，還有sun那消亡的solaris,還有,自家的Hurd。然後，總之，這樣新特性讓人的接受上。。。太慢了。
說近點的，fnotify glibc還沒有對應的包裝函數呢，futex和NPTL又是花了許久才進入主流的。libc是app和內核的橋梁，libc理應快速跟上內核的接口變化，但是glibc和內核不是一塊開發的，所以，這只是理想罷了。glibc還要去兼容不同版本的內核呢！
而內核也要去兼容不同版本的glibc.雙方都背負了太多的歷史包袱。glibc至今保留Linux Threads兼容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就唯一的和一個特定版本的內核綁定到一起了。http://www.linuxidc.com注意，VDSO只是隨內核發行，沒有在內核空間運行，這個不會導致內核膨脹。這樣內核和libc都不需要為兼容多個不同版本的對方而寫太多的代碼，引入太多的bug了。
當然，libc不單單有到內核的接口，還有很多常用的函數，這些函數不需要特別的為不同版本的內核小心編寫，所以，我估計Linux上會出現兩個libc,一個libc在內核，只是系統調用的包裹，另一個libc還是普通的libc，只是這個libc再也不需要花精力去配合如此繁多的kernel了。
