Messages in this thread | | | Date | Sat, 21 Jan 2006 11:31:27 +0100 | From | Pavel Machek <> | Subject | Re: RFC [patch 00/34] PID Virtualization Overview |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |