From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org ([140.211.166.183]:52590 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754532AbcHSBUD (ORCPT ); Thu, 18 Aug 2016 21:20:03 -0400 Date: Thu, 18 Aug 2016 10:46:07 -0700 From: Mike Frysinger To: Christoph Hellwig Cc: Jeff Layton , linux-fsdevel@vger.kernel.org, libc-alpha@sourceware.org, chrubis@suse.cz Subject: Re: [Linux PATCH] fcntl: add new F_OFD_*32 constants and handle them appropriately Message-ID: <20160818174607.GL21655@vapier.lan> References: <1471521804-4291-1-git-send-email-jlayton@redhat.com> <20160818170508.GA897@lst.de> <1471541300.2504.23.camel@redhat.com> <20160818173139.GA1140@lst.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4OpS+d6oOtUQaRm1" Content-Disposition: inline In-Reply-To: <20160818173139.GA1140@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --4OpS+d6oOtUQaRm1 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 18 Aug 2016 19:31, Christoph Hellwig wrote: > On Thu, Aug 18, 2016 at 01:28:20PM -0400, Jeff Layton wrote: > > That was my original thinking, but several people seemed to think that > > we should just go ahead and support it. TBH, I don't much care either > > way, but we either need to support it properly, or ensure that trying > > to use OFD locks in a non-LFS program fails to compile. >=20 > Yes, that's what glibc folks should do for now given that they still > seem to refuse being draggred into the present. >=20 > > The only real concern I have here is whether limiting this to LFS > > enabled programs might make it tougher to get this into POSIX. Would > > the POSIX standards folks object to having an interface like this that > > doesn't support non-LFS cases? I guess if that ever happens though, > > then we can just widen the support at that point. >=20 > LFS is perfectly Posix compliant (as is non-LFS). It's really just > a glibc (aka Linux) special to still support non-LFS modes. 4.4BSD > and decendants have made the switch to 64-bit off_t in 1994 and haven't > supported a non-LFS since. there's no need to be so dramatic here. glibc didn't write the LFS logic for fun, and hasn't maintained it out of laziness. in fact, the code is non-trivial to get right. the trade offs were considered heavily, and not breaking backwards compatibility was considered more important. otherwise we'd have a repeat of the libc4/libc5 (or gcc's libstdc++.so.5) breakage where all binaries stop working. BSD's can get away with it because their entire modus operandi is that you get no backwards compatibility. there has been discussion on the glibc lists for how we can move forward *safely*, but it's not something to be taken lightly -- LFS defines will implicitly change ABI structs all over the place. in the mean time, let's just drop the pointless inflammatory editorializing since it contributes nothing. -mike --4OpS+d6oOtUQaRm1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXtfRfAAoJEEFjO5/oN/WBVXQQAKIs49sl6ejqSxZG8eiGBDXr CJf/GC2JsKd4mDwFpdN/nXlkTqe6zaBusov5j4sHsCfCLBbonnbRf8JqUWrRivm3 /KuDOQOeUv/2u1fLnXE3dl3mrIXexD/od/zYF8mOTH7gsgq9iLs+/MHEp6A8+msq 5W3d/RRjlcwTPN/cFsey1TdSNl1Yd11M7i8aoHhCm3itxqGouJUQwQ21R3BBJUqX 1MAVGcufV5CKSBRfKbadvvaTBCdZGX1v9yK/p2MdS8reNrxcFe1pk/iTf8H4WJyI 4IHp7HwQ2xH2rVossd+1JWZHtze/7Lz1VhQYGJZUYfjf63JsavHZ4PQPxQ0P0e+/ k0NOp1yC/O7szb9pTbMF2KYydfx1ZlSTb0d6WUFVPnmEdegVE4PFIDdEuBTq9qyl GbR/+YURNYT6RsgfhX+WznP880/nLXfO1tb4IuGG2fA4MrSx2sk9/z3WrZAxRiZ1 cnZPyUtJTlssGwjxLSpcUAdHB8A/gOhDy8UpFlhzn8NK5XuPVIKYJXK3i3fwm3i4 OYVIOghv6581RVeXOOYks0du7RMyv9kgqI2PZlX51i9MTFgG6VVoFqB+coZ3bSNz fw3GyTYVo0aE5F7EIExPtr55TmJnZOMPci/6p0iD95kaaEOBVTgbNgZCk+CevOKv kv+elcMlXE0VNFQZyRyL =0h3r -----END PGP SIGNATURE----- --4OpS+d6oOtUQaRm1--