Re: RFC [patch 00/34] PID Virtualization Overview

[Pavel Machek]

On St 18-01-06 11:01:52, Dave Hansen wrote:
> On Tue, 2006-01-17 at 18:29 +0000, Alan Cox wrote:
> > On Maw, 2006-01-17 at 10:12 -0800, Dave Hansen wrote:
> > > You do assign new pids, at least as far as the kernel is concerned.
> > > However, any processes that continue to run would get confused if their
> > > pid changed.  You have to make sure that the tasks have a _consistent_
> > > view of which process is which pid.
> > 
> > Don't reassign the pid at all. Keep task->container and do the job
> > explicitly. Most task searches for a pid are abstracted already and most
> > users of ->pid who try and use it for comparing two tasks for equality
> > or for keeping a task reference are already terminally racey and want
> > fixing anyway.
> 
> Other than searches, there appear to be quite a number of drivers an
> subsystems that like to print out pids.  I can't find any cases yet
> where these are integral to functionality, but I wonder what approach we
> should take.  Should we deprecate printk'ing of pids?  Make a special
> function or % modifier to turn a task_struct into something printable?
> 
> A function would run into issues of having buffers in which to print the
> output.  But, we'd be able to do things like:
> 
> 	sprintf(buffer, "%d:%d", tsk->container, tsk->pid);

What about first fixing all the driver to print_task() or
something like that, where print_task would print name too (for
example). That way, we get more useful data *now* and you can fix it
any way you want in future.

char *print_task() doing pretty-printing should be enough.
							Pavel



-- 
Thanks, Sharp!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/