Olivier Péningault <[EMAIL PROTECTED]> writes: > - 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, ...)
I think this is the right way, no matter how the servers above this are designed. As for separation between user and kernel level, I don't know where to draw the line, but on least on mach it should probably be some kernel code that fiddles the registers on the ethernet card. I think one goal is to support several pfinets, you want to be able to run the old pfinet in parallell while hacking on the new networking code. Adapting the old pfinet to the new ethernet device should also be a simple sanity check of its design. > (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:) You need one piece of code that links between glibc and your ip interfaces, and that also performs packetforwarding, source and destination address selection, and such stuff. That code should be installed as the translator for /servers/socket/2. If you want to do ipv6 in such a way that an ipv6 socket can accept ipv4 connections, you also need some code that is aware of both ipv4 and ipv6. And my feeling is that it shouldn't be glibc's responsibility. > /servers/net/protocols/(ip4|ip6|icmp|arp|x25|tcp|udp|sctp|.......) Hmm. You could do something like that, but I don't think it makes sense to mix level 3,4 and 2 protocols like that. For instance, the only two pieces of code that need to know about arp should be (i) the code that implements ip-over-ethernet, and (ii) the arp program. In any case, I think for a start you should keep tcp and udp in the ip server. You want to minimize the number of rpc calls involved when a program calls send() until the packet is out on the wire. Keep it simple. > - 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 What will live on /servers/socket/2 then? That's the rendezvous point used by glibc. > Users will be able to add and use their own logical interfaces > in hurd-net. I'm not sure that makes sense. You shouldn't be able to manipulate the other user's networking, and don't think you want security (like keeping track of ownership of sockets and interfaces) in hurd-net/pfinet. If a user wants to hack his own networking stacks, it makes more sense to me that he runs his own pfinet, delegating some interfaces to the other pfinet. Hmm, that brings me to some other thing: Even if I don't quite buy the idea of making each protocol it's own process, I think it would make a lot of sense to define an rpc-interface representing one ip interface. pfinet could populate a directory with nodes representing available interfaces. That way, a parallel pfinet can send packets through interfaces in the system's pfinet. > I would like people here to discuss about it, and then (but not before > two monthes) I'll begin to implement it. Don't wait for too long for discussion. I think you can start hacking away on the level-two translators/devices right away. To get useful comments on the rest of the design, you should also start by specifying the interfaces you need. On one end, you have the interface between glibc and pfinet (the /servers/socket/*-translators), which you need to understand (I haven't looked at it myself so I have no idea what it looks like), on the other you have the interface provided by en ethernet or ppp translator. Another idea, which might just make sense: Abandon pfinet. Abandon the central networking server. Have only interfaces, living as nodes in the filesystem, on which one can read and write packet. Put the networking code *in the user process*. I.e. when I call socket(), connect() to create a tcp connection, I call some function in -lsocket that starts a thread does the tcp handling as a part of my own process. /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
