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不单单有到内核的接口，还有很多常用的函数，这些函数不需要特别的为不同版本的内核小心编写，所以，我估计Linux上会出现两个libc,一个libc在内核，只是系统调用的包裹，另一个libc还是普通的libc，只是这个libc再也不需要花精力去配合如此繁多的kernel了。