le jeu 24-10-2002 ŕ 21:49, Niels Möller a écrit : > 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. I spoke (not clearly) about it: there will ba a translator wich implements pfinet interfaces, and redirects calls to the new code in a good way. It will avoid porting programs and library urgently. But it will have do disapear one day...
> 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. ipv4 and ipv6 can run separatly. > 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. ip-arp-icmp are a problem, because this layer is divided in three protocols, each one has different goals. hurd-net will know how to manage that. But be carefull, protocols translators don't know the others one. The only translator of the stack who knows everybody is hurd-net. And we'll can have differences for the interfaces for the different layers; each layer has specific things to do, they all transmit datas (this could be a generic interface) but some of them have specific tasks (this could be a per-layer interface). per-layer interfaces will make ip-arp-icmp work "good" together. > 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. I agree; there will be (too) many rpcs, but I wouldn't like to do something ala pfinet, ie: all protocol mixed all together... > What will live on /servers/socket/2 then? That's the rendezvous point > used by glibc. Yes, it can. But maybe it is the translator which will tranform pfinet calls to hurd-net calls that will be there, and libc, ... will be adapted to the new interface step by step. > 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. Ok, i wasn't clear. Users can create interfaces, but they are only used and seen by them. Users can replace default interfaces, and use them, so when hurd-net will check interfaces and verify which one to use, user's rights will be an important information (but also the logical describer of the interface in hurd-net). When a user creates a new interface, rights are set to this user's rights. hurd-net can't be replaced, because it will contain important datas, such as addresses. The only thing users can do is multiplexing protocols, by setting up new network interfaces. > 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. Yes, but you need to centralize some datas, running many pfinet will not garantee that data is in sync in every pfinet (think about addresses, you must have a central repository, because you can't change them too easilly. hurd-net will have threads to implement logical-physical interfaces, but also thread(s) to answer requests about important datas stored in the net stack.). > 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. That's the way hurd-net works. We have default interfaces, with one thread per interface. Each time a new interface is created, - it exists, we update rights. - it does not exist, we create a new thread, which will autoconfigure itself (hum !! It is hard to explain, maybe I should write a paper with good explainations for these kind of ideas...). > Don't wait for too long for discussion. This is not for discussion only. I have many things to do, but I really will have time in the beginning of 2003. Before that, I will not do much work.... :( > > 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. That's right. Ok. > 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. I see what you mean. For the layer 3+ translators, at first I thought that it could be libraries, but concepts of the hurd are differents. How can users replace a library if they want ? Translators are better for this kind of features. olivier _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
