le jeu 24-10-2002 ŕ 09:59, Niels Möller a écrit : > My advice is that you start by designing and implementing some kind of > ethernetdevice (kernelspace or part kernel, part userspace translator) > that can support running several pfinets in parallell. Perhaps it > should look like the bsd tunnel devices, but I don't really know. > > Another possible design is to have a separate ip-over-ethernet process > that reads and writes ethernet frames on one hand, and ip-packets on > the other (doing arp and other ethernetspecific things). But one has > to be careful about the number of rpc calls needed to send a piece of > data over the network, perhaps ip-over-ethernet is better implemented > as a module in the pfinet process than as a separate process. This is nearly the idea I had.
- A translator per physical device, wich will present the upper side of a layer 2 protocol (ex: ethernet protocol over an ethernet card, ppp over a serial port, ...). It will be the link between the physical device mastered by the kernel, and upper things. Maybe users will can replace them ? For the moment, device drivers are in the kernel, but when they'll be in user space, they just will have to implement one more interface. (Then I don't want to do like in pfinet. Protocol code must not be part of a big translator, while replacing one protocol is too hard. Here is my idea:) - A large set of small translators, each of them implements only the functionalities part of one (and only one) protocol (layer 3 -> 5). They will be attached to nodes such as: /servers/net/protocols/(ip4|ip6|icmp|arp|x25|tcp|udp|sctp|.......) Users will easilly can change these tanslators. Maybe layer 2 protocols could exist here too, to build tunnels or bridges... - Finally, another translator (one for the whole system) named hurd-net, that will be the center of the stack. It will be a multi-threaded, non-replaceable, updatable by users, interface between a)users b)layer 3+ translators and c)layer 2 translators. It will be stored in /servers/net/hurd-net In fact, layer 2 translators will present _real_ physical devices to the system, while net-hurd will present many interfaces (physical and logical). Users will be able to add and use their own logical interfaces in hurd-net. layer 3+ translators will only be able to manipulate and transform packets as needed, network configuration and other data will be stored in the central translator. To understand well how hurd-net and layer 3+ protocol interact, you can see hurd-net as a protocol-switching and data-store translator. Real work (except configuration data management) is done in layer 3+ translators. To avoid the need of porting all programs in the same time if interfaces of networking change, a translator will can be used at first to wrap (correct word ?) pfinet interface with hurd-net interface in the users/programs side. Routing protocols, firewall, q.o.s. may be easy to add. I would like people here to discuss about it, and then (but not before two monthes) I'll begin to implement it. Comments ? :) olivier _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
