olafbuddenha...@gmx.net wrote:
One way I think of is to use a different RPC. Suppose it is called
mach_task_to_subhurd_task(mach_port_t subhurd_port, task_t task).
Therefore, the task in subhurd gets its task port with
mach_task_self() and translate it to subhurd task port with this
RPC.
Well, if we really need to modify the client-side code for obtaining
the task port, I guess a simpler and more efficient approch would be
to inject a send right for the pseudo task port into the process
address space at process creation time, and simply read that when
mach_task_self() is attempted. (Pseudo thread port is more tricky,
though.)
I doubt it can work. We can inject the send right to the process when
we create it, but the problem is how the process know the name of the
port (the name of port, I mean, is the integer value).
The right could be inserted under a fixed name (as already happens with
some ports AIUI), or the name could be stored at a known place in the
new process's address space, like the environment is...
But again, we should try to avoid client-side changes alltogether, if
possible. This is only a fallback solution; we do not need to consider
it for now.
I just found that there are two RPCs that can change the kernel ports of
tasks and threads: thread_set_kernel_port and task_set_kernel_port.
Mach does provide an easy way to override these two ports:-)
I will explore how to get the subhurd tasks from the process server of
main Hurd first.
I know the current task is to make subhurd run by all users, but I am
thinking that maybe we can create a completely isolated subhurd
(including the resource isolation). just a thought.
Zheng Da