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

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

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

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

于是乎，Linux的大牛們?cè)俅问钩鼋^招：讓libc變成VDSO進(jìn)駐內(nèi)核。

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

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

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

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

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

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

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

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

?