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

[Serhey Popovych]

Stephen Hemminger wrote:
> On Tue, 27 Feb 2018 21:34:56 +0200
> Serhey Popovych  wrote:
> 
>> Stephen Hemminger wrote:
>>> On Tue, 27 Feb 2018 14:06:50 +0200
>>> Serhey Popovych  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 
 Signed-off-by: Thomas De Schampheleire 
 Signed-off-by: Serhey Popovych 
 ---
  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  we need to include it in nearly all .c files as first
>> include file.
>>
>> I also start thinking on single  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  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
 . 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 .

  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).

> 




signature.asc
Description: OpenPGP digital signature

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

[Stephen Hemminger]

On Tue, 27 Feb 2018 21:34:56 +0200
Serhey Popovych  wrote:

> Stephen Hemminger wrote:
> > On Tue, 27 Feb 2018 14:06:50 +0200
> > Serhey Popovych  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 
> >> Signed-off-by: Thomas De Schampheleire 
> >> Signed-off-by: Serhey Popovych 
> >> ---
> >>  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  we need to include it in nearly all .c files as first
> include file.
> 
> I also start thinking on single  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  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.




pgpSss9aXfz0i.pgp
Description: OpenPGP digital signature

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

[Serhey Popovych]

Stephen Hemminger wrote:
> On Tue, 27 Feb 2018 14:06:50 +0200
> Serhey Popovych  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 
>> Signed-off-by: Thomas De Schampheleire 
>> Signed-off-by: Serhey Popovych 
>> ---
>>  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  we need to include it in nearly all .c files as first
include file.

I also start thinking on single  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  done using similar schema
that is reverted with this series.

> 




signature.asc
Description: OpenPGP digital signature

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

[Stephen Hemminger]

On Tue, 27 Feb 2018 14:06:50 +0200
Serhey Popovych  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 
> Signed-off-by: Thomas De Schampheleire 
> Signed-off-by: Serhey Popovych 
> ---
>  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.

Doing fine grained kernel and libc per file makes it more painful.