Well, this is what we have already. With my minor processes stuff, the
"virtual pid" can be found by checking if the process has PF_MINOR
set, if so its virtual pid is its ppid, otherwise its virtual pid is
its real pid.
The only issue with this is that if, for instance, you have fifty
normal processes, and one thread group with 500 threads, ps has a lot
of work to do in order to hide the threads. Having procfs hide the
threads is complicated, but might be a saving.
> >> 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.
>
> You planned to fix signal handling, right?
Well, at the moment I'm just trying to get the cost of a
pthread_create closer to the cost of a clone. Once that is done,
fixing signal handling (having minor process handle signals for the
manager) will be straightforward. But first I have to get hold of the
POSIX 1b spec so I can make sure I do it right.
> With that and the stuff
> you already wrote, I'd say you have a working CLONE_PID.
I should have a working CLONE_PID equivalent. It isn't CLONE_PID
because it doesn't.
> The current
> CLONE_PID looks like bad news for security and hasn't been useful.
> I would suggest that you just recycle the CLONE_PID name and bit.
We're not running short of clone flag bits just yet, and reusing the
name will only confuse people. When there's a fast complete pthreads
implementation for Linux with the kernel parts accepted by Linus, then
I'll be happy to give CLONE_PID the chop.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu