This is the mail archive of the
mailing list for the glibc project.
Re: Official Linux system wrapper library?
On Sun, 11 Nov 2018, Willy Tarreau wrote:
> > The kernel developers care not, and the result is that we
> > copy definitions and declarations from the kernel header files, creating
> > additional problems.
> Probably that these standard compatibility issues should be addressed at
> their root in the kernel header definitions in fact. Working around issues
> always leads to a stall at some point, and it encourages the process not
> to change.
But it's not a bug in the Linux kernel header files. The set of feature
test macros supported is libc-specific and libc-version-specific. The
internal macros defined as a result of the feature test macros, that
determine what features to expose, are also libc-specific and
libc-version-specific. (The __USE_* macros in glibc are not a stable API.
For example, we might move to using __GLIBC_USE for more features in place
of the defined/undefined __USE_* internal macros.)
If a feature is Linux-specific, and the userspace header for it is also
Linux-specific (as opposed to constants in standard headers such as
sys/mman.h, where you get all the namespace issues), that userspace header
*can* include uapi headers in many cases to get constants and structures -
if those uapi headers actually work in userspace without defining things
conflicting with libc types. E.g. <sys/fanotify.h> includes
What *is*, in my view, a bug in the uapi headers is that some of them
don't work when included on their own. I'd expect #include
<linux/whatever.h> or #include <asm/whatever.h>, for any such header
installed by make headers_install, to compile on its own in userspace
without needing any other headers to be included first, unless some header
is specifically defined as being an internal part of another header which
is the one that should be included.
In glibc we have scripts/check-installed-headers.sh which verifies that
installed headers work when included like that in various language
standard and feature test macro modes - and with my bots running
build-many-glibcs.py, this property is effectively verified every few
hours for (currently) 79 different glibc configurations covering all
supported glibc ABIs. If the uapi headers are fixed to work on their own,
there should be similar continuous integration to make sure that this
continues to be the case in future.
Simply having uapi headers that reliably work when included on their own
would help with adding further test automation in glibc to verify
consistency of constant and structure definitions between glibc and uapi
headers. We have a few such checks (e.g. for signal numbers), but now
that we require Python 3 to build glibc I hope to convert those into more
general infrastructure for extracting information from headers and running
checks on the extracted information.
Joseph S. Myers