Re: POSIX timers - need help understanding header file organization

[george anzinger <george at mvista dot com>]

Geoff Keating wrote:
> 
> > Date: Wed, 06 Mar 2002 20:32:03 -0800
> > From: george anzinger <george@mvista.com>
> > Organization: Monta Vista Software
> > X-Accept-Language: en
> > CC: libc-alpha@sources.redhat.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 "old versions" are for backwards binary compatibility with
> existing applications.  It's OK to provide higher resolution than they
> were expecting if this can be done without breaking them.  But you
> can't, for instance, change the size of 'struct itimerspec' or give
> CLOCK_REALTIME a new number, without providing backwards
> compatibility.  Additional CLOCK_* values are OK, because old
> applications will not use them and when they are not supported (the
> kernel is too old) an appropriate error code can be returned.
> 
> Old applications can't be _expecting_ high resolution timers, since
> when they were compiled they didn't exist.  So at the worst it's OK to
> just use the existing code for these old applications, and have new
> code for new applications.  It's usually more efficient to do some
> kind of translation instead, though.
> 
> > > - 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...
> 
> Well, the backwards binary compatibility with old applications lasts a
> very long time.  Distributions are still shipping libc5, for instance.
> 
> For old kernels, it's not so long.  I don't think glibc supports 1.x
> kernels any more (if it ever did).
> 
> All the backwards compatibility can be compiled out by using the
> appropriate configure options, if it's not needed for a particular
> system.
> 
> > > 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.
> 
> Unfortunately, that's what binary compatibility is all about: someone
> makes a mistake and it is paid for over many years in larger code
> size.  Happily, we have the technology available to still make
> improvements.
> 
So at this point I need to know a bit more about how the "old" POSIX
timers worked.  Any one know who did the code?  

I could try to decode the source, but it is a bit convoluted.  I, in
particular, need to understand how siginfo is handled and exactly where
(i.e. to which thread) the signals are delivered.  I made some
extensions to the standard here and need to know if they are compatible.

Oh, and I still need to understand header file organization.  I.e. where
and what is generated.
-- 
George           george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/