lkml.org 
[lkml]   [2005]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] [PATCH 00/13] Introduce task_pid api
    Quoting Paul Jackson (pj@sgi.com):
    > Serge wrote:
    > > But when one of the
    > > processes looks for process 10, task_vpid_to_pid(current, 10) will return
    > > the real pid for the vpid 10 in current's pidspace.
    >
    > So a "kill -1 10" will mean different things, depending on the pidspace
    > that the kill is running in. And pid's passed about between user
    > tasks as if they were usable system-wide are now aliased by their
    > invisible pidspace.
    >
    > Yuck. Such virtualizations usually have a much harder time addressing
    > the last 10% of situations than they did the easy 90%.

    For simplicity, the only pids a process will see are those in its own
    pidspace, and the only controls (I expect) will be the ability to start
    a new pidspace, and request a pid. So it is no more complicated than
    the vserver model, where a process becomes pid 1 only for other proceses
    in the same vserver, and process don't see processes in other vservers -
    except that now every process in the pidspace can be known as a different
    pid, not just the first.

    > How about instead having a way to put the pid's of checkpointed tasks
    > in deep freeze, saving them for reuse when the task restarts?
    > System calls that operate on pid values could error out with some
    > new errno, -EFROZEN or some such.

    Unfortunately that would not work for checkpoints across boots, or, more
    importantly, for process (set) migration.

    > This would seem far less invasive. Not just less invasive of the code,
    > but more importantly, not introducing some never entirely realizable
    > semantic change to the scope of pids.

    Hopefully the next patchset, implementing the pid-vpid split, will show
    it's not as complicated as I've made it sound.

    Of course, if it remains too complicated a conceptual change to be
    mergeable, we're better off knowing that now...

    thanks,
    -serge
    -
    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/

    \
     
     \ /
      Last update: 2005-11-15 03:32    [W:6.060 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site