This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: New way for syncing with kernel headers
- From: Jonathan Nieder <jrnieder at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 8 Dec 2017 11:49:09 -0800
- Subject: Re: New way for syncing with kernel headers
- Authentication-results: sourceware.org; auth=none
- References: <d758ff65-ed79-bceb-4001-4e9b4505c1ac@redhat.com>
Hi,
Florian Weimer wrote:
> Would this be an acceptable way to obtain definitions from the Linux headers
> in places where namespace cleanliness is not a must?
>
> /* Obtain the definitions of the MEMBARRIER_CMD_* constants. */
>
> #include <linux/version.h>
> #if LINUX_VERSION_CODE >= KERNEL_VERSION(4, 14, 0)
> # include <linux/membarrier.h>
> #else
>
> /* Definitions from Linux 4.14 follow. */
>
> enum membarrier_cmd
> {
> MEMBARRIER_CMD_QUERY = 0,
> MEMBARRIER_CMD_SHARED = 1,
> MEMBARRIER_CMD_PRIVATE_EXPEDITED = 8,
> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED = 16,
> };
>
> #endif
>
>
> The idea is to have a built-in fallback definition in case the installed
> kernel headers are too old. But for newer kernels, the UAPI header is used,
> to avoid duplicate definitions and a need for maintaining our own copy
> continuously.
>
> The inline copy of the definitions reflects what is needed for building
> glibc itself (including tests) and the manual. But if the end user installs
> newer kernel headers, their definitions are immediately available for use
> with glibc-based applications. Eventually, we can remove the inline copy
> once the minimum kernel version for building moves past the baseline
> requirement.
Sounds good to me! Some quick notes:
- I don't see any uses of LINUX_VERSION_CODE in glibc today except in
the configure script. Is there a reason to prefer
__LINUX_KERNEL_VERSION instead (maybe for a more stable namespace,
even in contexts where namespace polution is not an issue)?
- I'd worry about the LINUX_VERSION_CODE < 4.14 case bitrotting. Is
there an easy way to ensure it gets test-compiled e.g. as part of
build-many-glibcs?
Thanks,
Jonathan