From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-f68.google.com ([209.85.215.68]:43483 "EHLO mail-lf0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935879AbeCBHzw (ORCPT ); Fri, 2 Mar 2018 02:55:52 -0500 Received: by mail-lf0-f68.google.com with SMTP id q69so12081852lfi.10 for ; Thu, 01 Mar 2018 23:55:51 -0800 (PST) Subject: Re: [PATCH iproute2 1/3] ip: Fix compilation with kernel headers < 3.4 To: Stephen Hemminger Cc: netdev@vger.kernel.org, thomas.de_schampheleire@nokia.com References: <1519733212-30703-1-git-send-email-serhe.popovych@gmail.com> <1519733212-30703-2-git-send-email-serhe.popovych@gmail.com> <20180227090412.3de0f95e@xeon-e3> <88f6c9ea-3ac1-ba78-aeb3-03d37d5a0bb1@gmail.com> <20180228080745.73ab3f4f@xeon-e3> From: Serhey Popovych Message-ID: Date: Fri, 2 Mar 2018 09:55:43 +0200 MIME-Version: 1.0 In-Reply-To: <20180228080745.73ab3f4f@xeon-e3> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uXokGTG8972IveMeowIksTjZfHYL161aC" Sender: netdev-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uXokGTG8972IveMeowIksTjZfHYL161aC Content-Type: multipart/mixed; boundary="bfBILaOXwoqS9rAAZUl967NU2veYHBx7i"; protected-headers="v1" From: Serhey Popovych To: Stephen Hemminger Cc: netdev@vger.kernel.org, thomas.de_schampheleire@nokia.com Message-ID: Subject: Re: [PATCH iproute2 1/3] ip: Fix compilation with kernel headers < 3.4 References: <1519733212-30703-1-git-send-email-serhe.popovych@gmail.com> <1519733212-30703-2-git-send-email-serhe.popovych@gmail.com> <20180227090412.3de0f95e@xeon-e3> <88f6c9ea-3ac1-ba78-aeb3-03d37d5a0bb1@gmail.com> <20180228080745.73ab3f4f@xeon-e3> In-Reply-To: <20180228080745.73ab3f4f@xeon-e3> --bfBILaOXwoqS9rAAZUl967NU2veYHBx7i Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Stephen Hemminger wrote: > On Tue, 27 Feb 2018 21:34:56 +0200 > Serhey Popovych wrote: >=20 >> Stephen Hemminger wrote: >>> On Tue, 27 Feb 2018 14:06:50 +0200 >>> Serhey Popovych wrote: >>> =20 >>>> Since commit 596b1c94aa38 ("iproute: build more easily on Android"),= >>>> iproute2 uses types __kernel_long_t and __kernel_ulong_t but does no= t >>>> 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 unco= mmon >>>> 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 ++++++++++++++ =20 >>> >>> Why not just start a single file include/compat.h which is what >>> other software does. =20 >> >> 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 doi= ng >> single we need to include it in nearly all .c files as firs= t >> include file. >> >> I also start thinking on single and found it bit complicate= d >> than just adding header, (re)defining functionality and then include_n= ext. >> >>> >>> Doing fine grained kernel and libc per file makes it more painful. =20 >> >> Agree, and we already have done using similar schema >> that is reverted with this series. >=20 > This is a real rats nest. It all comes because kernel headers are inclu= ding asm/posix_types.h. > Normally, I would just clone that file out of kernel headers process, b= ut 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 compatibili= ty: 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). >=20 --bfBILaOXwoqS9rAAZUl967NU2veYHBx7i-- --uXokGTG8972IveMeowIksTjZfHYL161aC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJamQODAAoJEBTawMmQ61bBvusIAMTvx4jnOC2iTsbqXfoVtyfH jssBwlcJgvsL3f1lac0HnZJl8829Gylm9+1gryrfFUHOVzfAGbIjcGpJxMQwgJoA 5jGxEzlm5RNMoH5zIWR2fNdB39QpDLsONBGB+IQfzMfBLZ+J53kkVmk3c026cxHy tGUa3yMnK/xeFrrIcSH/vwtQ/oEy1e7QoB8qw/2sr3fd6E7zCu2k71EYCVP+PsiJ TZM2Qpni7DcVPGDk4xhQ7ZkAbkPfBCND+jPS3hiy/8p34+rPWVNJyJkzs7qIv9Fi WimLrhEZ1+fwmLEfSR2x7VyC+jQBb5hhHrcNOp4cHVGFXmBgeOp2+vPb44uE+ZA= =LeRN -----END PGP SIGNATURE----- --uXokGTG8972IveMeowIksTjZfHYL161aC--