--- Farid Hajji <[EMAIL PROTECTED]> 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 _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
