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]

more optimizations


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]