Linux核心特性之VDSO

    這段時間看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就唯一的和一個特定版本的核心綁定到一起了。注意，VDSO只是隨核心發行，沒有在核心空間運行，這個不會導致核心膨脹。這樣核心和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 設計的發展，將來應該不會再出現類似 Intel Pentium4 這樣懸殊的差距。而"快速系統調用指令"比起中斷方式的系統調用方式，還存在一定局限，例如無法在一個系統調用處理過程中再通過"快速系統調用指令"調用別的系統調用。因此，並不一定每個系統調用都需要通過"快速系統調用指令"來實現。比如，對於複雜的系統調用例如 fork，兩種系統調用方式的時間差和系統調用本身運行消耗的時間來比，可以忽略不計，此處採取"快速系統調用指令"方式沒有什麼必要。而真正應該使用"快速系統調用指令"方式的，是那些本身已耗用時間很短，對時間精確性要求高的系統調用，例如
getuid、gettimeofday 等等。因此，採取靈活的手段，針對不同的系統調用採取不同的方式，才能得到最佳化的效能和實現最完美的功能。