lkml.org 
[lkml]   [2020]   [Jun]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: sys/sysinfo.h clash with linux/kernel.h

i think the linux-api list is the right place for this
so adding it on cc.

* Rich Felker <dalias@libc.org> [2020-06-02 17:37:05 -0400]:
> linux/kernel.h is a uapi header that does almost nothing but define
> some internal-use alignment macros and -- oddly -- include
> linux/sysinfo.h to provide a definition of struct sysinfo. It's
> included only from 6 places in the kernel uapi headers:
>
> include/uapi/linux/lightnvm.h
> include/uapi/linux/ethtool.h
> include/uapi/linux/sysctl.h
> include/uapi/linux/netlink.h
> include/uapi/linux/netfilter/x_tables.h
> include/uapi/linux/mroute6.h
>
> However, it's also included from glibc's sys/sysinfo.h to provide
> struct sysinfo (glibc depends on the kernel for the definition). On
> musl, this produces a conflicting definition if both sys/sysinfo.h and
> any of the above 6 headers are included in the same file.
>
> I think the underlying problem here is that the same header is used
> for two very disjoint purposes: by glibc as the provider of struct
> sysinfo, and by other kernel headers as provider of the alignment
> macros.
>
> The glibc use is effectively a permanent contract that can't be
> changed, so what I'd like to do is move the macros out to a separate
> header (maybe linux/something_macros.h?) and have linux/kernel.h and
> the above 6 uapi headers all include that. Then nothing but
> linux/kernel.h would pull in linux/sysinfo.h.

i think providing a patch would make this happen faster.

ideally uapi would be reorganized such that it's clear
what headers are supposed to be compatible with inclusion
together with libc headers and what headers may conflict.

>
> Note that in practice this is a rather hard issue to hit since almost
> nothing needs sysinfo() at the same time as the above uapi interfaces.
> However it did come up in toybox, which is how I first (just today)
> learned about the conflict, so it seems like something that should be
> fixed.
>
> Rich

\
 
 \ /
  Last update: 2020-06-03 13:56    [W:2.179 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site