Messages in this thread | | | Subject | Re: [RFC] [PATCH 00/13] Introduce task_pid api | From | Dave Hansen <> | Date | Wed, 07 Dec 2005 10:09:56 -0800 |
| |
On Wed, 2005-12-07 at 18:55 +0100, Arjan van de Ven wrote: > > > Many of the interesting places that deal with pids and where you > > > want translation are not where the values are read from current->pid, > > > but where the values are passed between functions. Think about > > > the return value of do_fork. > > > > Exactly. The next phase will focus on such places. Hubertus has some > > stuff working that's probably not ready for LKML, but could certainly be > > shared. > > hmm wonder if it's not just a lot simpler to introduce a split in > "kernel pid" and "userspace pid", and have current->pid and > current->user_pid for that. > > Using accessor macros doesn't sound like it gains much here.. (but then > I've not seen the full picture and you have)
My first instinct was to introduce functions like get_user_pid() and get_kernel_pid() which would effectively introduce the same split. Doing that, we could keep from even referencing ->user_pid in normal code, and keep things small and simpler for people like the embedded folks.
For the particular application that we're thinking of, we really don't want "user pid" and "kernel pid" we want "virtualized" and "unvirtualized", or "regular old pid" and "fancy new virtualized pid".
So, like in the global pidspace (which can see all pids and appears to applications to be just like normal) you end up returning "kernel" pids to userspace. That didn't seem to make sense.
-- 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/
| |