Hi, On Thu, Jan 01, 2009 at 09:11:16PM +0000, Zheng Da wrote: > On Mon, Dec 22, 2008 at 10:04 AM, <olafbuddenha...@gmx.net> wrote:
> > 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. Which is always the case for rootless subhurd, so we should be fine :-) > > > 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. > It might already be out of topic because we don't need to deal with it > if the possible solution I found above works. Which solution do you mean? -antrik-
