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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux