This is the mail archive of the libc-alpha@sources.redhat.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]
Other format: [Raw text]

Re: need help understanding header file organization


> 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.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>


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