On Thu, Sep 23, 2010 at 01:11:36PM -0700, Andrew Morton wrote: > On Thu, 23 Sep 2010 15:48:01 +0200 > Michael Holzheu <holzheu@xxxxxxxxxxxxxxxxxx> wrote: > > > Currently tools like "top" gather the task information by reading procfs > > files. This has several disadvantages: > > <snip> > > 3. A new tool "ptop" (precise top) that uses the libraries > > Talk to me about namespaces, please. A lot of the new code involves > PIDs, but PIDs are not system-wide unique. A PID is relative to a PID > namespace. Does everything Just Work? When userspace sends a PID to > the kernel, that PID is assumed to be within the sending process's PID > namespace? If so, then please spell it all out in the changelogs. If > not then that is a problem! Good point. The pid ought to be valid in the _receiving_ task's pid namespace. That can be difficult or impossible if we're talking about netlink broadcasts. In this regard process events connector is an example of what not to do. > If I can only observe processes in my PID namespace then is that a > problem? Should I be allowed to observe another PID namespace's > processes? I assume so, because I might be root. If so, how is that > to be done? I don't think even "root" can see/use pids outside its namespace (without Eric's setns patches). If you want to see all the tasks then rely on root being able to do stuff in the initial pid namespace. If you really want to use/know pids in the child pid namespaces then setns is also a nice solution. Cheers, -Matt Helsley -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
