[lkml]   [2012]   [Apr]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] nextfd(2)
    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.

     \ /
      Last update: 2012-04-06 22:19    [W:0.045 / U:6.660 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site