Messages in this thread | | | Date | Tue, 14 Sep 2004 20:45:18 +0200 | From | Roger Luethi <> | Subject | Re: [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.
Roger - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |