Re: GSoC project about virtualization using Hurd mechanisms

[zhengda]

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
> solution?
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... :-)
>
> -antrik-
>   
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