Re: GSoC project about virtualization using Hurd mechanisms

[olafBuddenhagen]

Hi,

On Wed, Apr 09, 2008 at 12:49:28AM +0200, zhengda wrote:

> I read the code of pfinet, and find the implementation of TCP/IP stack
> is almost the same as the linux.

Indeed, it's the TCP/IP code from some older Linux version (2.0 I
think), only converted to run as a Hurd translator :-)

> pfinet uses libtrivfs to build the translator,

Right, libtrivfs is used for the basic setup, and to make the node look
like a file. The interesting part is the socket interface though, which
is not implemented by libtrivfs itself...

But well, that's not the topic at hand :-)

> The packet received by the driver is spread by the packet filter,
> which  specifies the destination of every copy of the packet. So I
> guess as long as the right packet filter is set, the kernel will  send
> the packet to pfinet.

Right.

> But, unfortunately, I cannot find any code in hurd which tries to set
> the packet filter.

It must be there somewhere in pfinet. From the followup mail I conclude
that you found it in the meantime?...


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

> pfinet calls  device_write() to send the packet to the packet. gnumach
> gets the packet from device_write(), and sends it to the  network,
> and, meanwhile, it sends one copy to the packet filter.

Yes, a patch to improve the packet filter code was included not so long
ago; IIRC filtering outgoing packets as well was one of the
improvements...

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

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

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

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