[lkml]   [2006]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: (pspace,pid) vs true pid virtualization
    Quoting Hubertus Franke (
    > >>- Should a process have some sort of global (on the machine identifier)?
    > First establish whether that global ID has to be persistent ...
    > I don't see why ! In which case the TASK_REF is the perfect global ID.

    The task_refs were only intended to be used in the kernel, iiuc.


    > >>- Should we be able to have processes enter a pid space?
    > >
    > >
    > >IMO that is crucial.
    > Existing ones .. now that is potentially difficult to do. Particular
    > if you want to enter a pidspace that has already been migrated.
    > Because ones assigned pid might already been taken in the target pspace.

    Well the answer changes depending on whether the question asks
    about pid spaces, or full containers. For full containers, you have
    problems with unsharing various pieces of namespace. But for the
    pidspace, a simple function with clone() semantics makes perfect sense.
    So your code does:

    child_pid = pidspace_clone(pspace_id);
    if (child_pid == 0) {
    /* we are inside pspace 'pspace_id' with a random
    pid which is unique in that pspace */
    } else {
    /* the child_pid is known by some other pid in it's
    own pspace, but in our pspace it's known and hashed
    by 'child_pid'. child_pid and that other pid are
    likely different.

    So long as we're just talking about the pidspaces, I don't see any
    unexpected side effects here.

    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-02-17 15:56    [W:0.025 / U:11.176 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site