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 <linux/fanotify.h>. 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 jos...@codesourcery.com
