Re: need help understanding header file organization

[george anzinger <george at mvista dot com>]

Geoff Keating wrote:
> 
> > Date: Wed, 06 Mar 2002 17:11:14 -0800
> > From: george anzinger <george@mvista.com>
> 
> > I am attempting to add the system call stubs for posix timers to the
> > library.  I have set it up so the stubs replace the library routines
> > conditioned on the __NR_<call name> being defined.  I think I have this
> > under control, BUT...
> >
> > The system calls have need of slightly different defines for some of the
> > CLOCK_  and other constants in the header files.  One way of doing this
> > is to condition the values again on __NR_<call name> being defined.  Is
> > this a "ok" way to do this or is there some other preferred method.
> 
> This is really not a good idea.  glibc needs to have the same API no
> matter what kernel happens to be installed (consider a system that
> switches between an older and a newer kernel version).  If the API
> should be modified, the best way to do this is to:

The API is sort of fixed by the standard, but there is a possibility of
adding additional CLOCKS and providing better resolution.  It is also
possible to extend some of the structures in a standard conforming way.
> 
> - Provide old versions of the routines that just translate the
>   constants and call the new routines

But then the new features are not available.  The whole point of the
exercise is to provide high resolution timers, something that is
impossible with the current code.

> - The new routines then call either the system call (if it is present)
>   or emulate the syscall (for the case of running a new glibc on an
>   older kernel).

How long do we carry this baggage?  There is also the very real
possibility that the system calls will be defined to do something else
on these older systems...
> 
> The detection of whether the syscalls are present should be done at
> runtime; for an example, look at libc/sysdeps/unix/sysv/linux/i386/chown.c.
> 
> --
This makes one wonder about the wisdom of providing POSIX timers without
kernel support in the first place.  Now you are telling us that we need
to live with this mess for some time.  It would have been better to have
just left a hole.
-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/