這段時間看Linux內(nèi)核源碼的時候，經(jīng)常碰到vdso這個東西(像在Feature-fixup中，獲取時間等操作時)，網(wǎng)上搜了一下，才知道了含義，原來這是Linux為了解決和glibc兼容而想出的絕招啊。下面是從Fedora中文郵件列表轉(zhuǎn)過來的，和大家分享一下。

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

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

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

于是乎，Linux的大牛們再次使出絕招：讓libc變成VDSO進駐內(nèi)核。

這里普及一下VDSO這個小知識，知道的人跳過，不知道的人讀一下：VDSO就是Virtual Dynamic Shared Object，就是內(nèi)核提供的虛擬的.so,這個.so文件不在磁盤上，而是在內(nèi)核里頭。內(nèi)核把包含某.so的內(nèi)存頁在程序啟動的時候映射入其內(nèi)存空間，對應(yīng)的程序就可以當普通的.so來使用里頭的函數(shù)。比如syscall()這個函數(shù)就是在linux-vdso.so.1里頭的，但是磁盤上并沒有對應(yīng)的文件.可以通過ldd/bin/bash看看。

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

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

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

Linux下傳統(tǒng)的系統(tǒng)調(diào)用是通過軟中斷(0x80)實現(xiàn)的，在一個Kernel.org的郵件列表中，有一封郵件討論了“"Intel P6 vs P7 system call performance”，最后得出的結(jié)論是采用傳統(tǒng)的int 0x80的系統(tǒng)調(diào)用浪費了很多時間，而sysenter/sysexit可以彌補這個缺點，所以才最終決定在linux內(nèi)核中用后都替換前者(最終在2.6版本的內(nèi)核中才加入了此功能，即采用sysenter/sysexit)。

如何用替換sysenter/sysexit替換以前的int 0x80呢?linux kenerl 需要考慮到這點：有的機器并不支持sysenter/sysexit，于是它跟glibc說好了，“你以后調(diào)用系統(tǒng)調(diào)用的時候就從我給你的這個地址調(diào)用，這個地址指向的內(nèi)容要么是int 0x80調(diào)用方式，要么是sysenter/sysexit調(diào)用方式，我會根據(jù)機器來選擇其中一個”(kernel與glibc的配合是如此的默契)，這個地址便是vsyscall的首地址。

可以將vdso看成一個shared objdect file(這個文件實際上不存在),內(nèi)核將其映射到某個地址空間，被所有程序所共享。(我覺得這里用到了一個技術(shù)：多個虛擬頁面映射到同一個物理頁面。即內(nèi)核把vdso映射到某個物理頁面上，然后所有程序都會有一個頁表項指向它，以此來共享，這樣每個程序的vdso地址就可以不相同了)

“快速系統(tǒng)調(diào)用指令”比起中斷指令來說，其消耗時間必然會少一些，但是隨著 CPU 設(shè)計的發(fā)展，將來應(yīng)該不會再出現(xiàn)類似 Intel Pentium4 這樣懸殊的差距。而"快速系統(tǒng)調(diào)用指令"比起中斷方式的系統(tǒng)調(diào)用方式，還存在一定局限，例如無法在一個系統(tǒng)調(diào)用處理過程中再通過"快速系統(tǒng)調(diào)用指令"調(diào)用別的系統(tǒng)調(diào)用。因此，并不一定每個系統(tǒng)調(diào)用都需要通過"快速系統(tǒng)調(diào)用指令"來實現(xiàn)。比如，對于復(fù)雜的系統(tǒng)調(diào)用例如 fork，兩種系統(tǒng)調(diào)用方式的時間差和系統(tǒng)調(diào)用本身運行消耗的時間來比，可以忽略不計，此處采取"快速系統(tǒng)調(diào)用指令"方式?jīng)]有什么必要。而真正應(yīng)該使用"快速系統(tǒng)調(diào)用指令"方式的，是那些本身運行時間很短，對時間精確性要求高的系統(tǒng)調(diào)用，例如 getuid、gettimeofday 等等。因此，采取靈活的手段，針對不同的系統(tǒng)調(diào)用采取不同的方式，才能得到最優(yōu)化的性能和實現(xiàn)最完美的功能。