往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。
学习了。
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
神作,膜拜!
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org 写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
学习
在 2010年12月10日 下午4:34,源泉星火(张明源) zhangmingyuan240@gmail.com写道:
神作,膜拜!
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org 写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
不懂微菜哥说什么。
[fedora@fedora-desktop ~]$ ldd /bin/bash linux-vdso.so.1 => (0x00007fff301b0000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fad19458000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fad19254000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fad1903e000) libc.so.6 => /lib64/libc.so.6 (0x00007fad18c9a000) /lib64/ld-linux-x86-64.so.2 (0x00007fad1967f000)
我的这个东东。是不是用 linux-vdso.so.1 替换 linux-gate.so.1 呢?我的是 2.6.36.2。
Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong
2010/12/10 刘红丹 hongdanliu@gmail.com
学习
在 2010年12月10日 下午4:34,源泉星火(张明源) zhangmingyuan240@gmail.com写道:
神作,膜拜!
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org 写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
-- 刘红丹 http://liuhongdan.com/ _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
学习了。
2010/12/10 Liang Suilong liangsuilong@gmail.com
不懂微菜哥说什么。
[fedora@fedora-desktop ~]$ ldd /bin/bash linux-vdso.so.1 => (0x00007fff301b0000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fad19458000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fad19254000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fad1903e000) libc.so.6 => /lib64/libc.so.6 (0x00007fad18c9a000) /lib64/ld-linux-x86-64.so.2 (0x00007fad1967f000)
我的这个东东。是不是用 linux-vdso.so.1 替换 linux-gate.so.1 呢?我的是 2.6.36.2。
Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong
2010/12/10 刘红丹 hongdanliu@gmail.com
学习
在 2010年12月10日 下午4:34,源泉星火(张明源) zhangmingyuan240@gmail.com写道:
神作,膜拜!
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org 写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
-- 刘红丹 http://liuhongdan.com/ _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
... ... 真单调 ...
在 2010年12月10日 下午5:54,Peng Huang shawn.p.huang@gmail.com 写道:
学习了。
2010/12/10 Liang Suilong liangsuilong@gmail.com
不懂微菜哥说什么。
[fedora@fedora-desktop ~]$ ldd /bin/bash linux-vdso.so.1 => (0x00007fff301b0000) libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fad19458000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fad19254000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fad1903e000) libc.so.6 => /lib64/libc.so.6 (0x00007fad18c9a000) /lib64/ld-linux-x86-64.so.2 (0x00007fad1967f000)
我的这个东东。是不是用 linux-vdso.so.1 替换 linux-gate.so.1 呢?我的是 2.6.36.2。
Fedora && Debian User, former Ubuntu User My Page: http://www.liangsuilong.info Fedora Project Contributor -- Packager && Ambassador https://fedoraproject.org/wiki/User:Liangsuilong
2010/12/10 刘红丹 hongdanliu@gmail.com
学习
在 2010年12月10日 下午4:34,源泉星火(张明源) zhangmingyuan240@gmail.com写道:
神作,膜拜!
在 2010年12月10日 下午4:20,microcai microcai@fedoraproject.org 写道:
往往内核添加了一个功能, glibc 要花很久才会用上。本来linux 那边为这个功能是否进入内核已经吵半天了,glibc 这边又要为是否使用这个内核新特性再次吵架半天 (glibc 不是 Linux 专有的,还得考虑 BSD (虽然人家也不用 glibc) SysV Windows(诶,这没办法) , 还有 sun 那消亡的 *** , 还有, 自家的 Hurd ) 然后,总之,这样新特性让人的接受上。。。 太慢了。
说近点的,fnotify glibc还没有对应的包装函数呢,futex 和 NPTL 又是花了许久才进入主流的。libc 是 app 和内核的桥梁,libc 理应快速跟上内核的接口变化 .. 但是 ... ... glibc 和 内核不是一块开发的,所以,这只是理想罢了。 glibc 还要去兼容不同版本的内核呢! 而内核也要去兼容不同版本的 glibc . 双方都背负了太多的历史包袱。glibc 至今保留 LinuxThreads 兼容2.4版本的古老内核。Linux 对已经没用,甚至有bug(接口的问题导致一些bug是必须的)的系统调用也必须保留,随知道用户会用哪个版本的glibc呢?虽然新的glibc 会使用新的调用,但是提供和老的调用一致的 API 来兼容,但是,用户只升级内核而不升级 glibc 是常有的事情. .. 就算升级了 glibc ... 你新版本的 glibc 一定就用上内核的新接口?!?!?!?! 还是再等几年等 glibc 的开发者吵架结束吧
于是乎,Linux 的大牛们再次使出绝招: 让 libc 变成 VDSO 进驻内核。
{ 这里普及一下 VDSO 这个小知识,知道的人跳过,不知道的人读一下 :D 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 了 .....
姑且一个叫 klibc, 一个叫 glibc : ... printf() 这些的还在 glibc 。 open() , read() , write(), socket() 这些却不再是 glibc 的了,他们在 klibc 。 _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
-- 刘红丹 http://liuhongdan.com/ _______________________________________________ Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
Chinese mailing list Chinese at lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/chinese
2010/12/11 microcai microcai@fedoraproject.org
在 2010年12月10日 下午5:10,Liang Suilong liangsuilong@gmail.com 写道:
不懂微菜哥说什么
... ... ... ... ... 悲催
強者的寂寞。XD
K410
在 2010年12月12日 下午4:08,Alvin qzhang.g@gmail.com 写道:
你怎么让应用程序选择link到klibc库还是glic库? 你可以CC zh-kernel一份
/usr/lib/libsyscall.so 可以是一个到 /proc/self/klibc.so 的软链接。
chinese@lists.fedoraproject.org