Thomas De Schampheleire wrote:
> On Mon, Feb 26, 2018 at 09:46:41PM +0200, Serhey Popovych wrote:
>> Since commit 596b1c94aa38e21b7a8c8562e8b61ccb744255d2, 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@gmail.com>
>> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
>> Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
>> ---
>>  include/linux/sysinfo.h |   14 ++++++++++++++
>>  misc/ss.c               |   10 ++++++++++
>>  2 files changed, 24 insertions(+)
>>  create mode 100644 include/linux/sysinfo.h
>>
>> diff --git a/include/linux/sysinfo.h b/include/linux/sysinfo.h
>> new file mode 100644
>> index 0000000..766de8d
>> --- /dev/null
>> +++ b/include/linux/sysinfo.h
>> @@ -0,0 +1,14 @@
>> +#ifndef _SYSINFO_COMPAT_H
>> +#define _SYSINFO_COMPAT_H
>> +
>> +/* In case the kernel header asm/posix_types.h is too old (< 3.4) to provide
>> + * __kernel_long_t, provide it here
>> + */
>> +#ifndef __kernel_long_t
>> +typedef long		__kernel_long_t;
>> +typedef unsigned long	__kernel_ulong_t;
>> +#endif
>> +
>> +#include_next <linux/sysinfo.h>
>> +
>> +#endif /* _SYSINFO_COMPAT_H */
> 
> Actually, I now wonder: instead of applying this trick with #include_next on
> sysinfo.h, why not do it on linux/types.h ? That would be more correct and more
> robust for the future, no?

No. Headers in include/uapi updated automatically from newer kernel
versions. If we do any hacks in iproute2 uapi directory updating headers
automatically would be problematic.

As for me using #include_next presents better approach.

Better to provide means for compatibility and that I propose to do with
series "ip: Provide compatibility bits to build with old glibc/kernel
headers".

> 
> /Thomas
>