You're right. CLONE_MINOR does different things in the two cases.
But when it's completed, CLONE_MINOR will have one meaning - to create
a new minor process as a member of the current thread group.
I could in fact introduce three clone flags:
1. CLONE_MINOR, create a process that can never have children (one day
will also imply threaded signal handling and that it waits of its
parent's wait queue).
2. CLONE_SIBLING_CREATOR, create a process that can create siblings.
3. CLONE_SIBLING, create a sibling.
This will introduce fiddly details, and I'm not convinced that the
distinctions are actually useful. So my intention is to go with a
CLONE_MINOR creates a child or a sibling depend on the case. That is,
unless someone gives an example of why the distinctions might actually
be useful.
> > should be easier than making CLONE_PID work properly, which would
> > require the same sorts of changes plus adding thread IDs and some new
> > syscalls).
>
> Maybe CLONE_PID ought to be your CLONE_MINOR. It would be very good
> to kill the current CLONE_PID, since /proc can not handle it.
> Let's think of /proc as having thread ID directories, not process ID
> directories. The process ID is equal to the thread ID of the manager
> thread. We just need a way to tell procps that not all threads in /proc
> are manager threads, perhaps with /proc/$TID/threads files.
This appears easy enough to do. The procfs code just has to omit minor
threads from the normal process listing, and put them in the directory
of the leader thread instead.
> I think CLONE_PID doesn't look so impossible if you redefine the
> contents of /proc as thread directories.
In principle completing CLONE_PID is not much more work than what I'm
doing. However, for every place where the kernel exposes a pid to
userspace, somene will need to consider whether a thread equivalent is
needed and if so write the code. Which sounds like a lot of trouble
for something we can do perfectly well without.
-- Dave Wragg- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu