[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking for the solution of rootless subhurd

From: Zheng Da
Subject: Re: looking for the solution of rootless subhurd
Date: Sat, 17 Jan 2009 01:38:11 +0000


On Thu, Jan 15, 2009 at 11:03 AM, <olafBuddenhagen@gmx.net> wrote:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]