Hi, On Sat, Jan 10, 2009 at 08:29:02PM +0000, Da Zheng wrote:
> 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:-) That's great news :-) I saw these RPCs when reading through the Mach documentation, but somehow totally failed to realize that the kernel port set there is actually the port returned by mach_task_self()/mach_thread_self()... > I will explore how to get the subhurd tasks from the process server of > main Hurd first. I wonder whether this is the preferable route. It seems that we will have to intercept the task/thread kernel ports in the subhurd anyways, to prevent set_priority() failing. And if we intercept them anyways, we could just as well also track task creation in the subhurd... So maybe it is better to explore this possibility first -- especially as it doesn't seem to require fixing fundamental design issues, which would seriously delay further progress... Of course the other route is interesting nevertheless: The problem with obtaining the task's owner is a generic one, not really limited to subhurd -- IMHO it should be fixed in any case. Also, in some use cases it should be acceptable to demand that the system running in the subhurd can cope with set_priority() failing -- 100% transparency is not always required... So I guess it could be made an option. In this case, it would be nice if we could get away without intercepting kernel ports. > 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). Indeed, while the primary goal is running subhurd as normal user, it is evidently a desirable variation to have a completely isolated subhurd. This is precisely why I suggested to make it an option whether the subhurd should see the user's other tasks, or only the subhurd tasks. -antrik-