From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org ([140.211.166.183]:52858 "EHLO smtp.gentoo.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755076AbcHSBZ7 (ORCPT ); Thu, 18 Aug 2016 21:25:59 -0400 Date: Thu, 18 Aug 2016 11:16:56 -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: <20160818181656.GQ21655@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> <20160818174607.GL21655@vapier.lan> <20160818175246.GA1433@lst.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gXx2FYK2AghGE4Yq" Content-Disposition: inline In-Reply-To: <20160818175246.GA1433@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: --gXx2FYK2AghGE4Yq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 18 Aug 2016 19:52, Christoph Hellwig wrote: > On Thu, Aug 18, 2016 at 10:46:07AM -0700, Mike Frysinger wrote: > > there's no need to be so dramatic here. glibc didn't write the LFS log= ic > > for fun, and hasn't maintained it out of laziness. in fact, the code is > > non-trivial to get right. >=20 > It hasn't maintained it out of lazyness, but out of stupidity - it's been > 20 years overdue to get rid of supporting non-LFS for _new code_. as i said, we've been discussing it of late, and it's a non-trivial problem. "just make it the default" ignores the fact that LFS shows up in many places and changes ABIs of downstream libs implicitly when they use impacted struc= ts. > Keeping > the old symbols around is perfectly fine. And at least a few years > ago I could run FreeBSD 1.x (pre-4.4BSD) code on recent FreeBSD systems > with the right compat defines in the kernel build and the compat libraries > just fine, so it's not like it's an unsolved problem. "and the compat libs" is a pretty key point. of course if your lowest ABI boundary is the kernel, things are much easier. you can do the same thing with libc5 today because the boundary is the Linux syscall ABI. the point is to *not* have to do that but keep using the same SONAMEs which does work under Linux/glibc today, and generally is what the BSDs do not care about. > At the same time glibc lazuness has caused us Linux developers tons of > problems due to applications or even system programs using the wrong > APIs as they still are the default, including random errors due to "too l= arge" > inode numbers or offset. the APIs need to stick around regardless of what glibc does moving forward.= =20 existing binaries aren't going anywhere. so if the compat syscals are brok= en, then they're broken and need fixing. > So yes, I'm pissed that this crap isn't sorted out and have all the reaons > to be "dramatic". which isn't terribly useful and is more likely to have people just ignore y= ou -mike --gXx2FYK2AghGE4Yq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXtfuYAAoJEEFjO5/oN/WBuikP/i8sb5HGUWFKZHLW9TJ+pH3r d/aEnsgHWKDl67lg/Q+/bh8sGmBcYyu8vB4LK6xLHwatWkzvsLhTcaVlF+EIrt5n lTPo383n89O1pRErsVnxxLk8kaGDiDgmTSJ1mb+0KTP2JiUrDmdzvQVcTPf5jfqe S0QGVGM/NjWyzJtogT9cNCW2QXOYP9UTMyKTzhyTnddNKHD6wYzcoh7Sxg1GF+fW IGuasUMukrlZb4f04Xb+NBt2Pe8WOfhVBuBmmfDnTqng9M/ndsYQM1DFjwAuvmV5 hZ/Tqkockdn+wt3n5hVFnj7WxQbnJr2ubSYc9OcizavHdFjBCub9iscvf7vwuYYN pJvg/gC9InoyUl6atk5wCURO9jaShMaekdQCK/7yfWUnCUdFXAZSTldn+jUmDoR6 BhF8YQXTO07KAcCVoI1CEO2DzbPj0b/RmvXSh/vqRrm0SiDJagJzUbaVgOXkj95h yTgcrEwl4RQDuckxfQfq04sMwLvDGK4hIi6dTPLcncN4J2vXUn6kM5syd8COcoW/ iUziUeCqiS3vSXpyB1oQ0qpeSz0VKEJIH9zlx0R/yYcSLVvI3luBwb1Dvok9qlsu lFtGSor/YzLRUyvwDnA/OxiKN/q41sTpU3dQH2pdq1M8jJiZ2DAzZkHVG9+FAvYl eHq7zBP/1fpapf6sPhOU =C/ZZ -----END PGP SIGNATURE----- --gXx2FYK2AghGE4Yq--