Re: [musl] [PATCH 1/1] uapi: Don't include <linux/sysinfo.h> in <linux/kernel.h>

Hi Rich,

On Thu, Oct 01, 2020 at 09:52:31PM +0200, Petr Vorel wrote:

quoted

+ update code where needed (include <linux/sysinfo.h> in code which
included <linux/kernel.h> only to get struct sysinfo or SI_LOAD_SHIFT).

quoted

The reason is to avoid indirect <linux/sysinfo.h> include when using
some network headers: <linux/netlink.h> or others [1] ->
<linux/kernel.h> -> <linux/sysinfo.h>.

quoted

This indirect include causes redefinition of struct sysinfo when
included both <sys/sysinfo.h> and some of network headers:

quoted

In file included from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/kernel.h:5,
                 from x86_64-buildroot-linux-musl/sysroot/usr/include/linux/netlink.h:5,
                 from ../include/tst_netlink.h:14,
                 from tst_crypto.c:13:
x86_64-buildroot-linux-musl/sysroot/usr/include/linux/sysinfo.h:8:8: error: redefinition of ‘struct sysinfo’
 struct sysinfo {
        ^~~~~~~
In file included from ../include/tst_safe_macros.h:15,
                 from ../include/tst_test.h:93,
                 from tst_crypto.c:11:
x86_64-buildroot-linux-musl/sysroot/usr/include/sys/sysinfo.h:10:8: note: originally defined here

quoted

[1] or <linux/sysctl.h>, <linux/ethtool.h>, <linux/mroute6.h>, <linux/ethtool.h>

quoted

Suggested-by: Rich Felker <redacted>
Signed-off-by: Petr Vorel <redacted>
---
Hi,

quoted

this looks to be long standing problem: python-psutil [2], iproute2 [3],
even for glibc in the past [4] and it tried to be solved before [5].

quoted

This will require glibc fix after:

You can't do this; it breaks the existing contract with glibc. New
kernel headers can't force a glibc upgrade.

Right, got that.

You just have to get rid
of use of <linux/kernel.h> elsewhere in the uapi headers. It was a
mistake that <linux/sysinfo.h> was ever separated out of
<linux/kernel.h> since it didn't (and couldn't) fix the contract that
<linux/kernel.h> exposes struct sysinfo (and that it's misnamed). But
it's no big deal. This can all be fixed without any breakage anywhere
just by not using it.

Back to your original suggestion to move the alignment macros to a separate
header. I was trying to avoid it not sure if introducing new header is
acceptable, but we'll see.

Rich

Kind regards,
Petr