From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37456 invoked by alias); 8 Dec 2017 23:52:51 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 37423 invoked by uid 89); 8 Dec 2017 23:52:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: vmicros1.altlinux.org Date: Fri, 08 Dec 2017 23:52:00 -0000 From: "Dmitry V. Levin" To: libc-alpha@sourceware.org Subject: Re: New way for syncing with kernel headers Message-ID: <20171208235246.GA26724@altlinux.org> Mail-Followup-To: libc-alpha@sourceware.org References: <20171208203235.GA24635@altlinux.org> <4d160f1a-93d5-ad40-de2c-b3049b3d8b59@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <4d160f1a-93d5-ad40-de2c-b3049b3d8b59@redhat.com> X-SW-Source: 2017-12/txt/msg00292.txt.bz2 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2128 On Fri, Dec 08, 2017 at 10:03:25PM +0100, Florian Weimer wrote: > On 12/08/2017 09:32 PM, Dmitry V. Levin wrote: > > On Fri, Dec 08, 2017 at 02:21:27PM +0100, Florian Weimer wrote: > >> Would this be an acceptable way to obtain definitions from the Linux > >> headers in places where namespace cleanliness is not a must? > >> > >> /* Obtain the definitions of the MEMBARRIER_CMD_* constants. */ > >> > >> #include > >> #if LINUX_VERSION_CODE >=3D KERNEL_VERSION(4, 14, 0) > >> # include > >> #else > >> > >> /* Definitions from Linux 4.14 follow. */ > >> > >> enum membarrier_cmd > >> { > >> MEMBARRIER_CMD_QUERY =3D 0, > >> MEMBARRIER_CMD_SHARED =3D 1, > >> MEMBARRIER_CMD_PRIVATE_EXPEDITED =3D 8, > >> MEMBARRIER_CMD_REGISTER_PRIVATE_EXPEDITED =3D 16, > >> }; > >> > >> #endif > >=20 > > Isn't it going to break when userspace uses e.g. > > LINUX_VERSION_CODE =3D=3D KERNEL_VERSION(4, 13, 0) > > and includes after this header? >=20 > Ugh, good point. >=20 > If I use 4.3 as the version guard (where was=20 > introduced first), someone with 4.13 kernel headers will not able to=20 > compile a test using MEMBARRIER_CMD_PRIVATE_EXPEDITED. So that doesn't=20 > work, either. >=20 > But if we copy the header contents, like we currently do in most cases,=20 > you can include the UAPI header afterwards, either. So maybe the=20 s/you can/you cannot/ > proposed approach is still an improvement because you don't have to=20 > include the UAPI header at all if your glibc version is sufficiently=20 > recent because the glibc header will give you the UAPI header plus=20 > whatever system call wrappers glibc provides. Yes, the proposed approach is an improvement. Relatively portable software would have to be able to include the UAPI header, too. Maybe we should document the least troublesome way of implementing this, e.g. #if defined HAVE_SYS_MEMBARRIER_H # include #elif defined HAVE_LINUX_MEMBARRIER_H # include #else # error membarrier API is not available #endif --=20 ldv --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature; name="signature.asc" Content-length: 801 -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaKyXOAAoJEAVFT+BVnCUIoyIQAJ+ZH3hqw76gQwQMY7S8ItYi wAvTy9wsy9A702GAF/XXuIplEw+oNwlY/6vyS6RMNpzxlbveKdgNkbCgh1OpxtqE rYczEctCOJAxM89tQXa9nIwjyLsJokjlOBJjlnZPxxPTwBh7ez2SBNYRN65wK4RT PJgAC4t6fhrO2bymTaDfGyE9CLTJXxspxQwpMiJfj5b4iyXsAoKxAuKyRRGRGnSv vKYtR/+Rfwsaj8hOoivx1ScTfSD6m2i10JCmmTR0/B7Sa+K9mxbMTybclWm4gVzX PYCYkpTMsRVCwlpoFEFoyCc6yarwHuPGFAtFDBMmUF+XDrVN6Z37SwOScO5RkpV1 yyiJric+1ukIJCT2LxTRDZ5n/dNTPpDzShxHcpVd3mXlhZv/9dUDo91G+JPWR/xf GKRVBUbLJV/T8eGI3eHB26mT9qFPbe9e3MDpFIfsStVym/zoZPcn3pIFvzlzMpbU Y423PwLI4Eox+HsHo5l65vDvLZG/t6nG3qCJBduP62uNUgYfFTndABoyzqsGoMzO VGMTtk1AEtkJt6b9FjBu4jt31zIhS54XCwVnVpe2FVV1/1uH7qt0nZMjIjMafXZ0 0e/lghMtxZhRzzyRjV/nD1La2Ixbl8XOYXzNnZb3sxf4AdVpgE70tWk4lLpxOFME /GvKvjBPVfWPfrHSpa5g =sFwW -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--