This is the mail archive of the libc-alpha@sourceware.org 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]

New way for syncing with kernel headers


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.

Header include ordering does not matter because <linux/membarrier.h> has its own include guard.

Has this already been tried?  Do you see any downsides?

Thanks,
Florian


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