Zheng Da wrote:
On Mon, Dec 22, 2008 at 10:04 AM, <olafbuddenha...@gmx.net
<mailto:olafbuddenha...@gmx.net>> wrote:
> The point here is that the process server needs to get all tasks in
> the host,
Yes, obviously it needs to. I understand your concern now, but I still
don't see an actual problem...
The first problem is how to get the all of these task ports without
root permission.
The second one is how to get all tasks that belong to a specific
subhurd. We can first just concern about the first problem for the
moment.
Note that the implementation of the pseudo master host port does not
need to forward the RPCs directly to Mach. (In fact, it can't even do
that, as it lacks the necessary privileges...) It can simply ask the
main Hurd's proc server instead.
I would hope that the proc server also has the necessary
information to
find out which tasks belong to the subhurd -- though I don't know for
sure...
I just found there is the RPC proc_getallpids, so I can get all
processes in the main hurd and then use pid2task to get their task
port. I also found that pid2task only works for the tasks that belong
to the caller. It almost solves my problem as long as the tasks
created in subhurd belong to the user of subhurd in the eyes of the
main Hurd.
I am afraid that it doesn't work. I mean boot cannot get all tasks in
subhurd from the main Hurd's proc server. I guess the reason is that the
tasks in subhurd cannot register themselves properly in the main Hurd's
process server and the process server doesn't know who the tasks in
subhurd belong to, and meanwhile, pid2task only works for the tasks that
belong to the caller.
So we return to where we were: how to get all tasks in subhurd?
We have to choose: either get all tasks from the kernel or track all
tasks in subhurd by boot.
Again, I believe it's very dangerous to return all tasks in the kernel
to the subhurd and it violates the original intention of creating subhurd.
Zheng Da