Re: abilist problems

[Roland McGrath <roland at redhat dot com>]

> - - do not run the script at all.  This should be triggered by a
>   --enable-XX option and maybe set by some other means

"configure --disable-check-abi" or "make enable-check-abi=no".

> - - don't take the results serious

What does that mean exactly? "make -k check" is good enough for me.  I have
just added an --enable-check-abi=warn mode, where the diff failures don't
abort make but instead print out "*** WARNING: blah".

> - - this is for real.

The current default (aka --enable-check-abi).

> In the last case make check should fail, in the former not.  The second
> flag should be set if, for instance, prefix != /usr, or we know that
> some functions will be missing.

I don't know what predicate "we know that some functions will be missing"
is supposed to indicate.  

> If check-abi is run it should always happen dead last and the output
> should contain a big warning in case some inconsistency is discovered.

People don't take *** as a warning?  I made it interleaved with the make
check subdir run so that it can be parallelized with other checks, check
each .so's dependencies only once, and have the whole thing finish quicker.

> Correct.  But some of these builds which are flagged as problematic are
> intended to miss functionality.  This is OK if the target kernel is old.
>  It is not OK if the default "make check" run fails.

It's ok if they produce functions that don't work at runtime.  
It's not ok if they produce binaries that are not dynamic-link-time compatible.

I think if you want to allow that you should use --disable-check-abi.
We could make --disable-sanity-checks disable it too.

> > If a function is intended to be a general part of the user API, the
> > proper thing to do is to give it a sysdeps/generic stub, and a
> > declaration in a non-sysdeps header or a sysdeps/generic version of the
> > relevant header.  If you do that, you always get the function in the ABI
> > even if just an ENOSYS stub.  Then how your build went is just a runtime
> > usability issue, and not an ABI compatibility issue at the symbol level.
> 
> Of course, but I think it's a waste to have all these unused stubs.
> They could be generated.  All they do is set errno to ENOSYS and return -1.

They also serve as an explicit placeholder in the source.  This provides a
template for what the function looks like, that a port-writer can copy and
edit.  And at least the original convention was to put a comment above the
function giving an informal specification of its interface that in most
cases is enough for a port-writer to know how to implement it.  I think
it's a good thing that this little bit of extra effort and formality be
required, because it makes a person pause and think deliberately about the
interface they are adding.  

> > When I wrote the syscalls.list mechanism, I did not anticipate the
> > practice of using EXTRA to add system calls unrelated to anything in any
> > makefile.  I still don't like it, because it encourages adding things to
> > the API/ABI willy-nilly for one configuration without regard to the
> > common glibc API and keeping it consistent across all GNU systems.
> 
> At that level there are necessarily differences since we don't control
> the Linux kernel and assuming that everything available on Linux will be
> available on hurd is probably not very welcome either.

We do control the glibc API.  Just because a system call is added to Linux
does not mean there must be a function by that name in glibc with the
identical API to the Linux system call.  For the things used only by one or
tow Linux-specific support programs, then people can just call syscall, or
have an extra library for the truly esoteric Linuxisms.  We are stuck with
things like uselib and mount because of the historical mistakes, but we
don't need to worsen it any more now or in the future.

If a new function is of general interest, then it should be investigated
and discussed first whether there is a clean interface that is not
intrinsically kernel-specific that can go into the generic glibc API.  This
was the case with the *xattr functions, for example.  Those got
sysdeps/generic versions and are now a fixed part of the Hurd libc ABI too
(so user programs can be built with xattr support), even though we have not
implemented them on the Hurd yet.

If epoll_* is something that users/application-writers want to use directly
(and not just used to implement some other standard layer like aio), then 
it is also an interface that can be presented cleanly as kernel-independent.
(It's pretty easy to implement for the Hurd, in fact.)

Adding a port-specific API should be the last resort, not the first.


> > But if syscalls.list is going to be used to add things to the API/ABI,
> > then I think it should be a rigid source specification of what goes in.
> > That is, the API and ABI should not be affected by what headers you
> > compile with.  The simplest thing is to make it a build error to have
> > the syscall number missing for an EXTRA syscall.
> 
> This will make it impossible to build glibc without the very latest
> headers.  This isn't acceptable.

It's already impossible to build a glibc you'd want to ship, because it
will be missing some functions that are part of the ABI it claims to support.
If they were made build errors, they could disabled by --disable-sanity-checks.

> Yes, it's not much harder but not wanted.  Having syscalls macros
> available or not will determine code generation.  If I know my code will
> only run on 2.2 kernels I don't want to have the dynamic checks for the
> new features in my libc.  This is a size and speed issues.  But allowing
> glibc to be compiled with whatever kernel header corresponds to the
> target system the resulting binary can be optimized for that specific
> target.

Sorry, I can't make much sense of this paragraph.

> I would like the automatic stub generation I hinted above to be implemented.

I have implemented it already, though differently than you described.
All stubs are aliases for a single entry point.



Thanks,
Roland