bug-hurd
[Top][All Lists]
Advanced

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

Re: GSoC project about virtualization using Hurd mechanisms


From: Zheng Da
Subject: Re: GSoC project about virtualization using Hurd mechanisms
Date: Fri, 4 Apr 2008 18:00:38 +0200

Hi,

I'll try to do it, but it will take a little long time because I have a lot of projects from my school these days.
So could you give me some more advices to help me get into the project faster? For example, which article or which part of code should I read first?

Best,
Zheng Da

On Fri, Apr 4, 2008 at 5:48 AM, <olafBuddenhagen@gmx.net> wrote:
Hi,

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
> subenvironments.

OK.

> 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.

Indeed.

> If we run another full set of servers, we can get  another Hurd on our
> machine. This is my understanding of how subhurd  works.

Correct :-)

> 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.

I see. So that would exactly match the "improve subhurds" subtask.

> 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.

It's not only about saving resources. A subhurd needs an own partition,
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
resource usage...

> 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.

That sounds like a pretty interesting use case :-)

> In  Hurd, we can run one server of networking for one IP. It should be
> easy   to be done in Hurd.

It is basically possible already (and used for subhurds); but as you
observed correctly, it requires some additional mechanisms to make it
suitable for what you want to do.

> Then we have to provide a mechanism to allow the  process to choose
> which server to use,

That matches another project idea: "Server Overriding Mechanism". It is
indeed closely related to the subenvironments idea; I already considered
merging them...

> and provide a mechanism to allow  servers communicate with each other.

Right. Presently it's possible to run multiple network stacks in
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
implemented?...

-antrik-




reply via email to

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