[lkml]   [2006]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: question: pid space semantics.
    On 3/14/06, Eric W. Biederman <> 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.
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-03-15 05:31    [W:0.020 / U:46.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site