Hi, On Thu, Jan 15, 2009 at 11:03 AM, <olafbuddenha...@gmx.net> wrote:
> 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 didn't realize it either when I read GNU Mach manual, but finally understand it when I read Mach 3 Kernel Principles:-) > > > > 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... which possibility? intercepting the task/thread kernel ports? I have to say it is also very difficult for me. So many RPCs have to be understood... but it should be a good practice:-) > > > > 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. I don't really accept this option. I see subhurd as a substitute of the virtual machine where can only run Hurd, at least, it's what I hope subhurd should be. Maybe subhurd was created with a differnet intention, I don't know. So if I runs two subhurd, what I wants is an isolated environment to do some experiments, but somehow the program in one subhurd can crash the other subhurd. Isn't it very strange? Since I think subhurd as a virtual machine, I hope it can give more control of resource usage to the user. For example, limit its memory usage (It's the only example I can think of now:-). Now subhurd can only use the devices specified by the user with "-m" option when it run by the normal user. Zheng Da
