[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACXRmJgUTN8kcT3KQS=kbQXwK9LhceehHYGYHobakTry2-+9zg@mail.gmail.com>
Date: Fri, 24 Feb 2023 14:04:47 +0100
From: Thomas Devoogdt <thomas@...oogdt.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: Thomas Devoogdt <thomas@...oogdt.com>, 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
Hi,
Unless you foresee hardware-specific logic, I would omit both asm and
asm-generic/. There must be a reason why it's not in the generic
included files, so including x86_64 is not a good idea I think. For
me, use-case, only socket.h, and libc-compat.h are useful and do not
include any asm{-generic}/ stuff, so it would be sufficient. Including
the others is for sure a good idea, since sooner or later userspace
could break again.
Kr,
Thomas Devoogdt
Op vr 24 feb. 2023 om 13:10 schreef Michal Kubecek <mkubecek@...e.cz>:
>
> On Fri, Feb 24, 2023 at 11:05:43AM +0100, Thomas Devoogdt wrote:
> >
> > I now remember (while looking at the other patches I had to add) that
> > I'm also missing __kernel_sa_family_t from /uapi/linux/socket.h (for
> > Linux < 3.7). So it's indeed not just libc-compat.h which is causing
> > problems. So perhaps take that one along while at it.
>
> At the moment, the full set to add would be
>
> linux/const.h
> linux/if_addr.h
> linux/if_ether.h
> linux/libc-compat.h
> linux/neighbour.h
> linux/posix_types.h
> linux/socket.h
> linux/stddef.h
> linux/types.h
>
> It looks like a lot but maintaining the whole uapi subdirectory can be
> fully scripted. Then I realized that there can be more than just linux/*
> and updated the script to pull in everything found in exported kernel
> headers. That added few more files:
>
> asm-generic/bitsperlong.h
> asm-generic/int-ll64.h
> asm-generic/types.h
> asm/bitsperlong.h
> asm/posix_types.h
> asm/types.h
>
> This is a bit more tricky as asm/* are architecture dependent. I suppose
> just taking x86_64 versions everywhere would be a bad idea for headers
> defining types. So I guess we may either omit asm/ or both asm-generic/
> and asm/. Neither is perfect and I'm not completely sure which option is
> safer.
>
> Michal
Powered by blists - more mailing lists