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):
    > How about adding the accessor routines in the first patch (still
    > referencing task->pid), then doing all the changes as you did, then
    > renaming task->pid to task->__pid and updating the accessor to that
    > change, in the last patch? Then it would build all the way through.

    Ok, thanks - will send out a new patchset to do this.

    >
    > Serge wrote:
    > > The resulting object code seems to be identical in most cases, and is
    > > actually shorter in cases where current->pid is used twice in a row,
    > > as it does not dereference task-> twice.
    >
    > You lost me here. Why does using these accessor routines avoid the
    > second reference?

    Why, I don't know :) I just looked at the resulting object code, and
    the static inline causes task->pid to be dereferenced once and pushed
    twice, whereas using task->pid causes it to be dereferenced twice.

    > Have you crosstool'd built this for most arch's? I could imagine

    No - I've never used crosstool, but will it a shot.

    > > Note that this does not change the kernel's
    > > internal idea of pids, only what users see.
    >
    > How can that be? Doesn't it run all accesses to the task->pid
    > field through the accessor, regardless of whether it's something
    > the user will see, or something used within the kernel?

    Ok... our intent is to not change the kernel pid concept :) Of
    course the accessor functions could be coded so as to change it, but
    as far as I know we will not do so.

    > How about other fields holding a pid, such as (one I happen to know
    > about) kernel/cpuset.c marker_pid? Grep for "pid_t" in include/linux
    > for other such possible fields. What about other kerel-user interfaces
    > that deal with pids such as fcntl, msgctl, sched_setaffinity, semop,
    > shmctl, sigaction, ...

    Yes, our next patchset will introduce the actual pid to vpid translations
    and place those functions in the right place. What I meant to say was
    that the kernel pids will still be pids just as they are now. The barrier
    between virtual pids and pids does not yet exist in this patchset. This
    patchset is to lay the groundwork to make those translations simpler. We
    switch task_pid() to task_vpid() in the right places, and use
    task_pid_to_vpid() at the barriers between pids and vpids.

    > How do you propose to synchronize incoming pid's with these potentially
    > modified displayed pids? There many invocations of find_task_by_pid()
    > in the kernel, typically converting a user provided pid into a task

    These are replaced with find_task_by_vpid(), which looks for a the given
    vpid in the pid-space of the calling process.

    > struct. If doing "kill(getpid(), 1)" in user code didn't sighup
    > myself, that would be uncool.
    >
    > How do you intend to use these accessor routines in order to help solve
    > the problems with checkpoint/restart?

    Let's say we want to start a process group. Start the first process in
    a new pidspace. (Hubertus or Dave can tell use exactly how this will be
    done in the first prototype, but I would expect something like
    echo 5 > /proc/$$/childpidspace
    start_my_program # This forks, and its children remain in pidspace 5
    )
    Now the processes in pidspace 5 are checkpointed and killed. When they
    are restarted, they will create a new pidspace for the group again, and
    ask for their checkpointed pids within that pidspace. Their kernelpids
    will still be the same pid it would have been. 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.

    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 01:45    [W:0.025 / U:212.572 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site