"Ulrich Drepper" <[email protected]> writes:
> On 3/14/06, Eric W. Biederman <[email protected]> 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.
Odd. I did not see that in Ingo's patches on the kernel list.
Perhaps only user space cares about storing the tid in the futex
field.
> 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.
The point of containers and their building blocks largely is isolation
so you can have multiple different user space environments on one
machine. So for most of the pieces that can really confuse user space
the answer is don't do that then. The classic example is pid files
for remembering a daemon is running.
Interactions do need to happen between pid spaces for certain
administrative actions, and as much as possible I don't want
to reinvent the wheel. Pid alases in the kernel are for
that purpose, and so will likely play a role in the RT signal
and the sysv shm case.
Eric
-
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]
