This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: argh!


On 19 Oct 1998 16:35:50 -0700, Ulrich Drepper wrote:
>I have restored the fstat.  Though I'm absolutely not pleased with
>this since the problem this patch solves but ultimately be solved
>differently.
>
>Anyhow, I haven't used Zack's complex patch which checks for effective
>O_DIRECTORY etc since it could introduce extra problems (who knows
>whether the implementation of open on all filesystems on a system is
>the same wrt opening file ending with a slash) and the saved time of
>fstat call is wasted in many ifs and larger code.

You can throw out tryopen_append_slash, but I think looking for
O_DIRECTORY at runtime is a good idea.  Calling fstat doesn't add much
overhead but calling stat does - it's a second traverse of the
directory tree.  linux 2.1 happens to do it fast because of the
dcache, but 2.0 is slow and most other Unixes - Hurd, Solaris,
possibly *BSD - are obscenely slow.

If we're counting cycles, two integer compares and two branches are
way faster than two system calls.  Most of the hair in there is to
avoid doing the complicated test twice.

>I think that during the glibc 2.2 development we will have to come up
>with a scheme which allows to eliminate effectively dead code.  E.g.,
>I'll certainly not run a 2.0 kernel anymore and therefore all
>compatibility code should be avoided.  Maybe somebody can already
>start thinking about this :-)

We already have support for selecting auxiliary libraries based on the
processor type; it shouldn't be too hard to extend that to OS revision
(call uname, or get the kernel to pass up its revision number in the
aux vector).

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]