[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180227101624.GM8100@australia>
Date: Tue, 27 Feb 2018 11:16:24 +0100
From: Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>
To: Serhey Popovych <serhe.popovych@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH iproute2] Fix compilation with kernel headers < 3.4
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@...il.com>
> Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@...ia.com>
> Signed-off-by: Serhey Popovych <serhe.popovych@...il.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?
/Thomas
Powered by blists - more mailing lists