?這段時間看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和內核不是一塊開發(fā)的，所以，這只是理想罷了。glibc還要去兼容不同版本的內核呢！

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

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

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

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

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

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

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

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

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

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

?