[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230223211735.v62yutmzmwx3awb2@lion.mk-sys.cz>
Date: Thu, 23 Feb 2023 22:17:35 +0100
From: Michal Kubecek <mkubecek@...e.cz>
To: Thomas Devoogdt <thomas@...oogdt.com>
Cc: netdev@...r.kernel.org, Thomas Devoogdt <thomas.devoogdt@...co.com>
Subject: Re: [PATCH ethtool] uapi: if.h: fix linux/libc-compat.h include on
Linux < 3.12
On Thu, Feb 23, 2023 at 09:38:41PM +0100, Thomas Devoogdt wrote:
> Hi,
>
> I now see that these headers are simply synced with (and even
> committed to) the upstream kernel. So having a kernel version check
> there is probably not something we want to do. Better would be to
> incorporate the "libc-compat.h" header as well to fix compilation on
> Linux < 3.12. This is similar to the added "if.h" header itself in
> commit https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/commit/uapi/linux/if.h?id=0b09751eb84178d19e4f92543b7fb1e4f162c236,
> which added support for Linux < 4.11.
>
> Let me know what you think, and if further action is needed from my
Yes, adding libc-compat.h would be a cleaner solution than having
a modified version of one header file. The easiest way should be
creating a bogus header file (e.g. "touch uapi/linux/libc-compat.h") and
running the ethtool-import-uapi script.
Seeing that this is not the first problem of this type - and likely not the
last either - I'm considering if we shouldn't go all the way and prevent
mixing potentially incompatible kernel header versions by pulling every
kernel header included in the source (and every kernel header included
by those etc.). That's something that could be scripted easily so I'm
going to try it and see how big the full set would be.
Michal
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists