[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1sZ7CUwQ-fUCS-z4CkhgSiNqzPcc_MTc2D54-8vfmV=g@mail.gmail.com>
Date: Sat, 21 Nov 2020 22:25:35 +0100
From: Arnd Bergmann <arnd@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Miller <davem@...emloft.net>,
Networking <netdev@...r.kernel.org>,
Christoph Hellwig <hch@....de>, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH net-next] compat: always include linux/compat.h from net/compat.h
On Sat, Nov 21, 2020 at 6:52 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> We're about to do some reshuffling in networking headers and make
> some of the file lose the implicit includes. This results in:
>
> In file included from net/ipv4/netfilter/arp_tables.c:26:
> include/net/compat.h:57:23: error: conflicting types for ‘uintptr_t’
> #define compat_uptr_t uintptr_t
> ^~~~~~~~~
> include/asm-generic/compat.h:22:13: note: in expansion of macro ‘compat_uptr_t’
> typedef u32 compat_uptr_t;
> ^~~~~~~~~~~~~
> In file included from include/linux/limits.h:6,
> from include/linux/kernel.h:7,
> from net/ipv4/netfilter/arp_tables.c:14:
> include/linux/types.h:37:24: note: previous declaration of ‘uintptr_t’ was here
> typedef unsigned long uintptr_t;
> ^~~~~~~~~
>
> Currently net/compat.h depends on linux/compat.h being included
> first. After the upcoming changes this would break the 32bit build.
>
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> ---
> Not sure who officially maintains this. Arnd, Christoph any objections?
Looks good to me. I would actually go one step further and completely
remove this #ifdef, if possible. In the old days, it was not possible to
include linux/compat.h on 32-bit architectures, but now this should just
work without an #ifdef.
Arnd
Powered by blists - more mailing lists