Subject: Re: [PATCH iproute2 1/3] ip: Fix compilation with kernel headers < 3.4

From: Stephen Hemminger <[email-masked]>
Date: Wed, 28 Feb 2018 08:07:45 -0800

On Tue, 27 Feb 2018 21:34:56 +0200
Serhey Popovych <[email-masked]> wrote:

> Stephen Hemminger wrote:
> > On Tue, 27 Feb 2018 14:06:50 +0200
> > Serhey Popovych <[email-masked]> wrote:
> >   
> >> Since commit 596b1c94aa38 ("iproute: build more easily on Android"),
> >> iproute2 uses types __kernel_long_t and __kernel_ulong_t but does not
> >> provide internal definitions for it.
> >>
> >> This means that compilation using kernel headers that are older than 3.4
> >> (where these types were added) will fail. This situation may be uncommon
> >> for native compilation, but not uncommon for cross compilation where the
> >> toolchains may be a bit older.
> >>
> >> Provide the necessary types internally if not provided by the kernel
> >> headers to fix compilation in such cases.
> >>
> >> Co-Developed-by: Serhii Popovych <[email-masked]>
> >> Signed-off-by: Thomas De Schampheleire <[email-masked]>
> >> Signed-off-by: Serhey Popovych <[email-masked]>
> >> ---
> >>  Makefile                              |    5 ++++-
> >>  include/compat/kernel/linux/sysinfo.h |   14 ++++++++++++++  
> > 
> > Why not just start a single file include/compat.h which is what
> > other software does.  
> 
> Yes it is good, but not for our case. We use include_next to define
> __kernel_long_t and __kernel_ulong_t types if they not defined. If doing
> single <compat.h> we need to include it in nearly all .c files as first
> include file.
> 
> I also start thinking on single <compat.h> and found it bit complicated
> than just adding header, (re)defining functionality and then include_next.
> 
> > 
> > Doing fine grained kernel and libc per file makes it more painful.  
> 
> Agree, and we already have <netinet/tcp.h> done using similar schema
> that is reverted with this series.

This is a real rats nest. It all comes because kernel headers are including asm/posix_types.h.
Normally, I would just clone that file out of kernel headers process, but the file
is arch specific which doesn't help.