This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Hi, I just checked in a few changes which allow removing compatibility code for older kernel versions. This is fully optional with no changes to the generated code if no such thing is wanted. It is currently only really implemented for Linux/x86 though there are not many non-x86 Linux files left. I simply haven't done the rest of the work since I'm not sure about the numbers. I've chosen to implement a way where the sources are modified. An alternative approach was discussed which was about putting the information in the filesystem but this seemed to be too much work and would slow down compilation even more. The current way to select the kernel version is by the configure option --enable-kernel=VERSION where version is something like 2.2.0. I hope it really works, it's only lightly tested. Zack at one time suggested to select the kernel via the configuration name, e.g., configure i686-pc-linux-gnu-2.2.2 or something like this. I think this is more confusing. Selecting to elide the compatibility code should happen explicitly. The way the testing works is by defining appropriate macros (e.g., __ASSUME_REALTIME_SIGNALS) in a file named kernel-features.h. There currently is only a Linux version of it. Of course this file is always only in the OS specific parts of sysdeps/. Based on the selected kernel version (or version 0.0.0 if none is given) various features are marked as known to exist. Changes to the source files will then elide the compatibility tests. In addition, if there is a minimal version given, in init-first.c a test for the current kernel version is performsed. This ensure the library can actually work. So, what is it good for? Well, the library size drops by about 8k or so (which is about 1%). What is more important is that the dynamic linker size drops by 4.5k which is 6.5% (all number on x86). So, I think it's well worth it. If you have comments or want things to be solved differently, speak up now. There still is time to change this. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |