Re: RFC [patch 13/34] PID Virtualization Define new task_pid api

[Kirill Korotaev]

Hello all,

> > > 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.
But our VPID patch is much less intrusive and shorter (thanks to Alexey 
Kuznetsov).
I will send a broken-out patches today CC-ing you.

BTW, have you tested it somehow (LTP, etc.)?

> 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.  

Kirill

-
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/