Re: [1/1][PATCH] nproc v2: netlink access to /proc information

[Roger Luethi <rl@hellgate.ch>]

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.

Roger