[Linux PATCH] fcntl: add new F_OFD_*32 constants and handle them appropriately

[Mike Frysinger]

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.
> 
> Yes, that's what glibc folks should do for now given that they still
> seem to refuse being draggred into the present.
> 
> > 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.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20160818/a0cabd81/attachment.sig>