Re: question: pid space semantics.

["Ulrich Drepper" <drepper@gmail.com>]

On 3/14/06, Eric W. Biederman <ebiederm@xmission.com> wrote:
> The question:
>   If we could add additional pid values in different pid spaces to a
>   process with a syscall upon demand would that lead to an
>   implementation everyone could use?

Before going into this, how do propose to solve some other issues:

- RT signal contexts have a si_pid field which contains the PID of the
sender.  When and how do you fix this up?  Can a process which is not
visible in a second PID space send a signal to a process in that
second PID space?

- similar problem: SysV IPC.  How do you fix up fields like msg_lspid
in struct msqid_ds?

- the proposed futex extensions for robust and maybe PI mutexes needs
to store the TID in the futex field.  If the futex shared by processes
in different PID spaces this value is worthless.

It would perhaps be conceivable to fix up the first two problems in
some cases.  If the process is visible in the PID space of the
receiver of the signal or the process which calls msgctl() etc the
kernel could magically fill in the correct PID for the PID space.  But
what to do if the process is not visible?

And for the futex case, the kernel is not involved in the fast path. 
There is no magic fixup which can happen.

I don't see at all how any of these things can work without breaking
all kinds of code.