What is unreliable about it? This is starting to be ridiculous. As far as automounting /proc is concerned, this does not seem to be a significant problem with current userspace. Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote: >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. -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- 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
