Re: "network administrator" in GNU/Hurd

[Hisham Kotry]

--- Farid Hajji <farid.hajji@ob.kamp.net> wrote:
> Sure, this is exactly the kind of problems we're
> dealing with
> when running multiple network stacks.
> 
> If you have two interfaces (and don't want to route
> or bridge
> across them), you can attach one network stack per
> sub-hurd
> and interface. Of course, this is not very
> practical, yet it
> is a start.

That was the theory in first place, but then when you
come to running multiple OSs atop of L4, like the Hurd
and Sawmill running side-by-side, you'll prefer to
have Sawmill's network stack[1] ipcs' sent to a module
-in the Hurd's network device driver server- exporting
linux's interfaces. Otherwise you'll go back to the
concurrent access problem. You can't just say, I'll
use eth0 with the Hurd and eth1 with Sawmill, in that
case any user could start a sub-hurd and use eth1
without anything stopping him. Note that asking root
for permision to access the NIC directly from a
sub-hurd every time you want to work on your own
network stack is defenitly not an option.

> Exporting virtual interfaces looks like a much
> better choice.
> Could you please write more about this?

Its still a vague idea, when l4-hurd's device driver
starts to stabalize we'll have a better picture on how
this should work. Note that once we have the concept
of virtual interfaces, their usage wont be restricted
to giving sub-hurds network access, you could also,
for example, use them as an interface to configure
remote network devices (ie. you could have interfaces
from around your network appear as if they're local
interfaces on some central server, that should ease
configuration). Linux will do something similar to
that with Netlink2, and we'll need that for
collectives.

> How would you bridge traffic?

Virtual interfaces will appear in the system as any
other regular interface, and they'll pass traffic of
the same type of the underlying physical interfaces
(ie. vif0 will export an ethernet interface if its
atop eth0, token-ring if its atop tr0, etc..), and
they'll have their own locally-asigned MAC addresses,
then we'll have nothing exceptional to do, just bridge
according to the IEEE's 802.1D std (or 802.1Q if
you're assigning vlans to sub-hurds :)). The only
diffrence here is the way packets arrive at an
interface, in linux, bridging means -more or less-
putting the new device in skb->dev after copying the
packet multiple times (packet/dev) and then calling
netif_rx to send it up the stack, this doesn't work
for us. As every interface (real or virtual) might
have a seperate stack doing its processing (this means
that each device driver might have a diffrent way to
pass packets up to the stack, shared memory, ipc with
a string item or fpage, whatever..), we can't just
change the device pointer and send it up. Lately, it
was brought to my attention that the solution I had
for this problem was similar to the way eCos's
ethernet drivers are written, so I'll just refer you
to [2] rather than filling up your mailbox :).

Cheers,
kotry

[1] http://www.zib.de/hupfeld/Diplomarbeit.pdf

[2]
http://sources.redhat.com/ecos/docs-latest/ref/io-eth-drv-generic.html
Sidenote: You probably only want to read the calling
graph to get a general idea of how it should work.

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com