On Sun, Aug 25, 2013 at 11:32:45AM -0700, Linus Torvalds wrote: > On Sat, Aug 24, 2013 at 10:23 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > > > > We are really stuck with the current semantics here - switching to > > *BSD one would not only mean serious surgery on descriptor handling > > (it's one of the wartier areas in *BSD VFS, in large part because > > of magic-open-really-a-dup kludges they have to do), it would change > > a long-standing userland API that had been there for nearly 20 years > > _and_ one that tends to be used in corner cases of hell knows how many > > scripts. > > Actually, I'm pretty sure we did have the "dup" semantics at one point > (long ago), and they were really nice (because you could use them to > see where in the stream the fd was etc). It just fit so horribly badly > into the VFS semantics that it got changed into the current "new file > descriptor" one. Afaik, nothing broke. > > So I'm not really sure about the "we're stuck with it" for semantic > reasons, and it turns out that very few programs/scripts actually use > /proc/<pid>/fd/<nr> at all (random use of /dev/stdin is likely the > most common case). But I agree about the "serious surgery on > descriptor handling" part. Well... We are actually in better position for that these days; right now we have very few instances of ->atomic_open(), so we could change the calling conventions for it. It returns 0 or -error and we could turn that into NULL, ERR_PTR(-error) or a reference to already opened struct file. It's not _that_ far to propagate from that point - atomic_open() <- lookup_open() <- do_last() <- path_openat(). So the amount of surgery is nowhere near the horrors we used to need (and *BSD actually does). We could try that, but I'm really afraid that semantics changes will break stuff; worse yet, that it'll happen to stuff in dusty corners of random admin scripts nobody able to debug anymore ;-/ -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
