Messages in this thread | | | Subject | Re: [PATCH] nextfd(2) | From | "H. Peter Anvin" <> | Date | Fri, 06 Apr 2012 13:33:19 -0700 |
| |
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@gmail.com> 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.
| |