On Sat, Aug 24, 2013 at 11:24:32PM +0200, Willy Tarreau wrote: > I doubt it. It seems to me that most such entries are implemented > for completeness while most valid uses only concern /proc/self/fd. > Maybe if we had an option so that only /proc/self/fd would actually > allow to access the fds while all /proc/pid/fd would only show what > they map to, it would be a good step forward. How? The fundamental problem is not visibility of that stuff, it's new opened file for the same object (Linux behaviour) vs. new descriptor refering to the same opened file (*BSD and friends). We can't get anon_... sanely reopened in the former semantics and they are very visibly different for regular files, so switching to *BSD one is not feasible - too high odds of userland breakage. The difference in semantics, of course, is that on Linux opening /dev/stdin gives you a descriptor with independent current IO position; on *BSD you get a descriptor sharing the current IO position with stdin. IOW, it's independent open() of the same file vs. dup(). 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. -- 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
