[lkml]   [2004]   [Sep]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [1/1][PATCH] nproc v2: netlink access to /proc information
    On Tue, 14 Sep 2004 10:43:25 -0700, William Lee Irwin III wrote:
    > On Tue, 14 Sep 2004 09:37:12 -0700, William Lee Irwin III wrote:
    > >> Not particularly. It largely means poorly-coded apps may report gibberish.
    > On Tue, Sep 14, 2004 at 07:15:25PM +0200, Roger Luethi wrote:
    > > If we are still talking about the same thing here, gibberish is a rather
    > > strong word. In the design I proposed access control affects the subset
    > > of tasks returned as a result -- the tool would still display meaningful
    > > information for the tasks it got replies for.
    > That sounds bizarre. I'd expect some kind of reply, even if merely an
    > error. I suppose "no reply" could be interpreted as "ESRCH", though
    > this means distinguishing between "some field caused an error" and
    > "the thing is dead" means the app has to fall back to requesting fields
    > one at a time.

    I suppose you are thinking of a request that lists a number of PIDs along
    with a number of field IDs. In that case yes, I agree that it makes sense
    to provide some explicit feedback to the tool once we add access control
    (before that, there is no ambiguity: a missing answer means ESRCH).

    The most common request, though, won't provide a list of pids, it will
    only provide a list of field IDs and select all processes in the system
    (NPROC_SELECT_ALL). There is no ambiguity here, either: The tool didn't
    ask for any specific process to begin with, ESRCH doesn't make sense
    here. And for a system that looks anything like /proc does today,
    fields that are capable of triggering EPERM are few and far between,
    certainly not something you are hitting unexpectedly in the fast path
    of a process monitoring tool.

    Thanks, by the way, for all the feedback that helped me realize that
    I have so far failed to explain the design well enough. I will try to
    work on that.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:06    [W:0.022 / U:7.804 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site