On Fri, Apr 06, 2012 at 09:14:17AM -0700, H. Peter Anvin wrote: > On 04/06/2012 02:54 AM, Alexey Dobriyan wrote: > > > > I agree, this particular changelog may be somewhat out of line. > > > > But I find it little hypocritical that kernel developers add CONFIG_PROC_FS, > > fix compilation problems associated with it, do not mount proc by default, > > do not mark it unmountable somehow and > > then say procless setups aren't worth it. > > > > Aren't worth *optimizing for*. But yes, CONFIG_PROC_FS is pretty much a > historic relic at this point, and probably should just be dropped. What to do with automounting /proc so it availablility would match syscall availability? > > Without proc knowledge about fdtable is gathered linearly and still unreliable. > > With nextfd(2), even procful environments could lose several failure branches. > > What? Please explain how on Earth this would "lose several failure > branches." closefrom(3) written via nextfd(2) loop is reliable and doesn't fail. closefrom(3) written via /proc/self/fd is reliable and can fail (including ENOMEM). closefrom(3) written via close(fd++) is unreliable. If programmer adds nextfd(2) loop before any closefrom(3) code he currently uses, there will be less failures. -- 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
