[lkml]   [1997]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectpatch for CLONE_PID enhancements to clone()
    Hello Everybody,

    I have made a patch against 2.1.57 that introduces the start of some
    functionality for clone() called with CLONE_PID.

    I have put it at
    for reference for anybody who wants to examine what I am doing and
    on it. I could also post it to this list but the size (about 30K) may
    be too
    big for that. It is not advisable to use it as it is now, as I found
    trying it that it breaks shutdown (but nothing else that I noticed :).
    I have probably messed up kill_proc() wrt init, but I haven't looked
    into it yet.

    The idea is to allow the CLONE_PID flag to have cloned tasks (not just
    on SMP) be able to share PIDs, and this patch makes some of the changes
    I thought were neccessary for this. Note that nothing has been done
    proc yet, as I don't know exactly how to handle hashing the pid/tids
    the proc inode space.

    Most of the changes in this patch are simple changes due to the
    following change in sched.h. I have taken a number of fields out of
    struct task struct and placed them into a separate structure called
    struct process_struct, along with the addition of a 'struct
    process_struct * ps' in struct task struct. When thinking about
    processes that shared pids it didn't seem right that things like the
    uid, gid, groups, ... were different. So, if CLONE_PID is specified in
    the clone flags then threads created reference the same struct
    process_struct. I have put anything that seemed like it should go into
    this structure into this structure, but I would like comments about
    the appropriateness of my choices and whether I have missed anything
    rlim ?).

    As to the other changes, things like do_fork() have been modified to
    set the tid field, and some of the system calls that had pid arguments
    have new varients that take both a pid, and a tid (sys_kill,
    sys_wait4, ...), but these have not been exposed to the user yet via the

    syscall mechanisms.

    Here is the new structure in question:

    struct process_struct {
    /* new fields:
    int last_tid, next_safe;
    int count;
    spinlock_t pslock;
    /* things that were in task_struct:
    int pgrp;
    int tty_old_pgrp;
    int session;
    /* boolean value for session group leader */
    int leader;
    int ngroups;
    gid_t groups[NGROUPS];
    unsigned short uid,euid,suid,fsuid;
    unsigned short gid,egid,sgid,fsgid;
    struct tty_struct *tty; /* NULL if no tty */

    I have also added an 'int tid' field to task_struct for holding the
    thread id. This seemed much simpler than encoding the tid in the upper
    pid bits, and doesn't break any experimental code that is currently
    using those bits for other stuff. Within process_struct are also a few
    new fields that weren't in task_struct: last_tid, next_safe, count,
    and pslock.

    o last_tid, and next_safe are comparable to the global next_safe

    and last_pid variables in fork.c for the do_fork() pid
    o count is a for a reference count on the process struct so that
    doesn't get deleted while some other task is referencing it.
    o pslock is for SMP locking of this structure. Note that I have
    only started putting locks in a few places so far. However if
    this patch was integrated into the kernel nothing should break

    SMP-wise because nothing should be using the CLONE_PID clone()


    I would appreciate any comments and suggestions. Thank you,


     \ /
      Last update: 2005-03-22 13:40    [W:0.021 / U:48.136 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site