[lkml]   [2005]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] [PATCH 00/13] Introduce task_pid api
    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.

    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?

    Have you crosstool'd built this for most arch's? I could imagine
    some piece of code having a local or other struct variable named 'pid'
    that would be broken by a mistake in this change. This could be so
    whether the change was done by a script, or by hand. Probably need
    to test 'allyesconfig' too.

    > 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?

    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, ...

    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
    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?

    I won't rest till it's the best ...
    Programmer, Linux Scalability
    Paul Jackson <> 1.925.600.0401
    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: 2005-11-15 00:39    [W:0.020 / U:74.900 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site