From: Mike Frysinger <vapier@gentoo.org>
To: Christoph Hellwig <hch@lst.de>
Cc: Jeff Layton <jlayton@redhat.com>,
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
Date: Thu, 18 Aug 2016 11:16:56 -0700 [thread overview]
Message-ID: <20160818181656.GQ21655@vapier.lan> (raw)
In-Reply-To: <20160818175246.GA1433@lst.de>
[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]
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 logic
> > for fun, and hasn't maintained it out of laziness. in fact, the code is
> > non-trivial to get right.
>
> 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 structs.
> 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 large"
> inode numbers or offset.
the APIs need to stick around regardless of what glibc does moving forward.
existing binaries aren't going anywhere. so if the compat syscals are broken,
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 you
-mike
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2016-08-19 1:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-18 12:03 [Linux PATCH] fcntl: add new F_OFD_*32 constants and handle them appropriately Jeff Layton
2016-08-18 13:24 ` Cyril Hrubis
2016-08-18 13:54 ` Jeff Layton
2016-08-18 14:06 ` Cyril Hrubis
2016-08-18 17:05 ` Christoph Hellwig
2016-08-18 17:28 ` Jeff Layton
2016-08-18 17:31 ` Christoph Hellwig
2016-08-18 17:46 ` Mike Frysinger
2016-08-18 17:52 ` Christoph Hellwig
2016-08-18 18:16 ` Mike Frysinger [this message]
2016-08-18 19:01 ` Zack Weinberg
2016-08-18 19:36 ` Paul Eggert
2016-08-19 13:20 ` Zack Weinberg
2016-08-19 15:02 ` Joseph Myers
2016-08-19 15:45 ` Zack Weinberg
2016-08-19 16:58 ` Joseph Myers
2016-08-19 19:50 ` Zack Weinberg
2016-08-18 20:52 ` Joseph Myers
2016-08-25 11:53 ` Florian Weimer
2016-08-25 12:05 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160818181656.GQ21655@vapier.lan \
--to=vapier@gentoo.org \
--cc=chrubis@suse.cz \
--cc=hch@lst.de \
--cc=jlayton@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).