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
Attachment:
signature.asc
Description: Digital signature
