On Tue, Apr 01, 2008 at 07:39:07PM +0200, zhengda wrote:
> There are two choices for me: to improve subhurds and to create a new
> In my understanding, Hurd is a set of servers which provide the
> services provided by the monolithic kernel before such as file
> system, networking and etc. These servers run as normal processes on
> a microkernel such as Mach or L4, whose responsibility is to help
> servers communicate with each other. Because of this architecture, it
> is possible for us to run duplicate servers.
> If we run another full set of servers, we can get another Hurd on our
> machine. This is my understanding of how subhurd works.
I see. So that would exactly match the "improve subhurds" subtask.
> But currently there are no communication channels between the subhurd
> and the main one, and no mechanism for safe sharing of hardware
> devices. This could be the task of the project.
It's not only about saving resources. A subhurd needs an own partition,
> In the other hand, if we can run some duplicate servers, we can get a
> smaller subenvirnoment which lives within the main system and uses
> most of its facilities. The advantage is that we can get a virtual
> subenvironment but save a lot of resources on the computer.
a complete bootup, and runs totally isolated from the main system
instance. That can be very useful properties in some cases (similar to
some traditional virtualization solutions); but the administrative
burden, the slow startup, and the lack of easy interaction make them
totally unsuitable in some other situations -- even when ignoring
That sounds like a pretty interesting use case :-)
> The virtual network I mentioned above is actually a network simulator.
> Its work is to simulate a network in the operating system, so
> different processes in the operating system think they are running on
> different IPs.
It is basically possible already (and used for subhurds); but as you
> In Hurd, we can run one server of networking for one IP. It should be
> easy to be done in Hurd.
observed correctly, it requires some additional mechanisms to make it
suitable for what you want to do.
That matches another project idea: "Server Overriding Mechanism". It is
> Then we have to provide a mechanism to allow the process to choose
> which server to use,
indeed closely related to the subenvironments idea; I already considered
Right. Presently it's possible to run multiple network stacks in
> and provide a mechanism to allow servers communicate with each other.
parallel on the same network device (in subhurds for example), and each
one can make and receive connections under it's own IP (thanks to the
packet filter in Mach) -- so they appear like multiple individual hosts
on the network. But unlike with true hosts, it's not possible for them
to communicate among each other... This is actually a feature I'm
missing myself :-)
This doesn't exactly match the subenvironments subtask. (It actually
leans a bit towards the subhurd task... This shows that the subtasks are
actually closely related and can't be clearly separated.) However, it
definitely falls within the hurdish virtualization task :-)
I know that it's hard for someone new to this stuff: but could you try
to investigate this a bit and make some proposal(s) how it could be