Message-ID: <a3dd885f-ac47-a271-6612-66f6668e3b39@gmail.com>
Date:   Fri, 2 Mar 2018 09:55:43 +0200
From:   Serhey Popovych <serhe.popovych@...il.com>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     netdev@...r.kernel.org, thomas.de_schampheleire@...ia.com
Subject: Re: [PATCH iproute2 1/3] ip: Fix compilation with kernel headers <
 3.4

Stephen Hemminger wrote:
> On Tue, 27 Feb 2018 21:34:56 +0200
> Serhey Popovych <serhe.popovych@...il.com> wrote:
> 
>> Stephen Hemminger wrote:
>>> On Tue, 27 Feb 2018 14:06:50 +0200
>>> Serhey Popovych <serhe.popovych@...il.com> 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 <serhe.popovych@...il.com>
>>>> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>
>>>> Signed-off-by: Serhey Popovych <serhe.popovych@...il.com>
>>>> ---
>>>>  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.
>

Anyway I'm still thinking that using include_next and separate kernel
and libc directories is most flexible schema to provide/track compatibility:

  1) No need to modify each .c file in package by adding custom
     <compat.h>. No need to track places where we need to include it.

  2) Way to tweak kernel/libc headers at first place and then
     continue with system/uapi headers via include_next.

  3) It is possible to completely replace system/uapi header by just
     putting it in correct location under comat/ in the same way we
     already did for <netinet/tcp.h>.

  4) Single place for all compat stuff: no need to add compatibility:
     easy to track changes.

So at the moment we have two possible approaches:

  1) Use comat directory and include_next

  2) Provide single comat.h header file and include it in all .c
     (or at least utils.h and some .c that does not include it).

Is this correct? Other options are welcome. If you prefer to use
compat.h I can prepare series, but at this moment I think this could
potentially have side effects (like missing include of compat.h in
some .c files in some setups).

> 




Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)

Powered by blists - more mailing lists