Messages in this thread | | | Date | Tue, 17 Jan 2006 09:56:00 -0600 | From | "Serge E. Hallyn" <> | Subject | Re: RFC [patch 13/34] PID Virtualization Define new task_pid api |
| |
Quoting Arjan van de Ven (arjan@infradead.org): > On Tue, 2006-01-17 at 08:33 -0600, Serge Hallyn wrote: > > plain text document attachment (BC-define-pid-handlers) > > Actually define the task_pid() and task_tgid() functions. Also > > replace pid with __pid so as to make sure any missed accessors are > > caught. > > This question was asked a few times before without satisfactory answer: > *WHY* this abstraction. > There is *NO* point. Really. > > (And if the answer is "but we want to play tricks later", just make a > current->realpid or whatever, but leave current->pid be the virtual pid. > Your abstraction helps NOTHING there. Zero Nada Noppes).
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.
However we could make the patch far less invasive by skipping the task_pid() macro altogether. Switching current->pid to current->__pid was to make sure we catch any ->pid accesses which we may have missed, during compilation.
Is that approach (keeping task->pid as the real pid and dropping the task_pid() macro) preferred by all?
-serge
- 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/
| |