Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Dave Hansen <haveblue@us.ibm.com>]

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/