Messages in this thread | | | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api | From | Dave Hansen <> | Date | Tue, 17 Jan 2006 09:25:14 -0800 |
| |
On Tue, 2006-01-17 at 16:03 +0000, Alan Cox wrote: > On Maw, 2006-01-17 at 09:56 -0600, Serge E. Hallyn wrote: > > The virtual pid is different depending on who is asking. So simply > > storing current->realpid and current->pid isn't helpful, as we would > > still need to call a function when a pid crosses user->kernel boundary. > > This is an obscure, weird piece of functionality for some special case > usages most of which are going to be eliminated by Xen. I don't see the > kernel side justification for it at all.
At least OpenVZ and vserver want very similar functionality. They're both working with out-of-tree patch sets. We each want to do subtly different things with tsk->pid, and task_pid() seemed to be a decent place to start. OpenVZ has a very similar concept in its pid_task() function.
Arjan had a very good point last time we posted these: we should consider getting rid of as many places in the kernel where pids are used to uniquely identify tasks, and just stick with task_struct pointers.
> Maybe you should remap it the other side of the user->kernel boundary ?
We would very much like to run unmodified applications and libraries. Doing it in a patched libc is certainly a possibility, but it wouldn't make any future customers very happy.
I also wonder if RedHat or SUSE would ever ship and support a special set of libraries for us. Oh, and there are always statically linked apps... :)
-- Dave
- 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/
| |