[Top][All Lists]

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

Re: GSoC project about virtualization using Hurd mechanisms

From: zhengda
Subject: Re: GSoC project about virtualization using Hurd mechanisms
Date: Thu, 10 Apr 2008 14:14:06 +0200
User-agent: Thunderbird (X11/20080213)

olafBuddenhagen@gmx.net wrote:
On Wed, Apr 09, 2008 at 11:45:15PM +0200, zhengda wrote:

In hurd, pfinet registers a filter when it open the ethernet device
(this ethernet device can be thought as a stub, right?), so it can
receive the packet it wants from the network.

Sorry, no idea what you mean by "stub" here...
What I mean is that ethernet.c in pfinet is developed as a bridge to connect pfinet and the real ethernet driver in mach.
Never mind, it's not important.

If we set the filter well, I believe the pfinet can get the copy. (But
I  haven't gone through the code of the packet filter, so I'm not sure
about it)

Sounds plausible :-)

If it works, does it mean pfinet servers have already been able to
communicate with each other?

Well, it doesn't work for me: I get "destination host unreachable"...

I suggest you try it yourself: Create a subhurd, set up pfinet in it
with an own IP address, verify that you can talk to both the main system
and the subhurd by using the respective IPs (you should be able to open
on ssh connection to either one for example), and finally test whether
you can talk from one to the other...

Perhaps it's necessary to do some additional setup in pfinet to make
sure the packet filter properly handles the outgoing packages?

If it could be made to work, it would certainly be the easiest solution,
though I'm not sure whether it would be the most elegant...
I will try.
What I mean is the mechanism provided by the packet filter provides us a possible solution. I don't expect it works now:-) As I can see, ether_filter in pfinet is hard coded. I think it's better to allow the user to set up the filter according to their own requirement.
The communication between two pfinet may work by changing ether_filter.
I find a paper talking about it: Efficient Packet Demultiplexing for Multiple Endpoints and Large Messages.
I'll tell you more after reading the paper.
By the way, gnumach provides BPF and MPF. But pfinet seems to use MPF? but why is BPF also provided?
And why do you not think it's an elegant solution?
I think it's very nice if it works.
If it doesn't work, I have another proposal: We reimplement the
functions in ethernet.c, which sends the packet to  other pfinets.

You mean the pfinets would directly talk to each other? Well, I guess
that should be doable, though somehow it doesn't sound right... Could
you try to examine possible advantages and disadvantages of such a
It's really better to use the packet filter (and I believe it will work:-)
The only advantage I can see is that this solution needs an extra server to route the packet for pfinets, and we can do many things in the extra server: We can simulate the network traffic, for example. We can control the transmission speed and whether there is a traffic jam, and so on.
One solution is that every pfinet sends its packets to one process
which  decides the destination for every packet. In this case, the
extra  process just works like a virtual network driver.

Indeed, one possible approach I was vaguely contemplating was to have
such a server sitting between the kernel device and the network stacks,
and do routing between them -- serving as a hypervisor basically.

The interesting question is how to configure the routing. Having an
extra interface for that would be awkward, so probably it should mirror
the kernel packet filter somehow...
At first, I thought the user could set the routing information by using the extra interface provided by the server.
now think of it, it's really not a good solution.
The benefit of the solution is that we can do many things in the extra
process to simulate the network.

Ah, so you don't want to touch the actual hardware device at all, but
rather create a purely virtual network? Well, that's certainly an
option, and maybe actually more useful for what you want to do -- but
less useful in general I believe... :-)

Actually I don't like this solution(by sending the packet to another pfinet rather than going through the network driver first) so much.
It's an option in case that it doesn't work by only using the packet filter.

Zheng Da

reply via email to

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