Olivier Péningault <[EMAIL PROTECTED]> writes: > le jeu 24-10-2002 ā 21:49, Niels Möller a écrit : > ipv4 and ipv6 can run separatly.
Sure, but do you really want them to run fully separately? It's common (although not required by any standard, afaik), that an ipv6 socket bound to the ipv6 wildcard interface should be able to accept ipv4 connections. > 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. arp is a lot different from icmp. arp is a link-layer mechanism that only the ip-over-ethernet code should need to worry about. But in order to do tcp, tcp, ip and icmp are used together. I'm all for code separation, but I'm afraid that putting the implementations into separate *processes* will just add unnecessary complexity to the system, for no real gain. > 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. I don't buy this. By adding ownership information and access control into hurd-net, you make things a lot more complex than they need be. You'll likely end up with something a lot more complex than the current pfinet. A guiding principle is that anything that can't be easily replaced by users should be as small as possible. Also note that the current pfinet *can* be replaced by users, the only real problem is that the ethernet device can't deal with that, so you'll need a separate ethernet card for each pfinet. So a hurd-net server that can't be replaced would actually be a step backwards. > > 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. That's not pfinet's, or even the hurd's, problem. If I start my own pfinet, then I'm going to need a new ip address. So I'll get one from the dhcp server, or ask whoever manages my local network for a static address. For configuration purposes, different pfinets are as separate as different machines, even if they may share the same ethernet device. If different pfinets need to share a lot of information, the design is broken. > - it does not exist, we create a new thread, which will autoconfigure > itself Configuration should happen the same way as if you connect a new machine to the network. If that can be done automatically (dhcp, autoaddress configuration, etc), that's nice of course, but that's mostly independent of the pfinet redesign, I think. > 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. Have a look at libstore. It can handle various kinds of stores, like partitions, devices, files, gzipped files, etc. These store modules can even be loaded dynamically when needed. If you have a gzipped file mounted as an ext2 filesystem, there will be rpc:s to the underlying filesystem where the gzipped file lives, and there will be clients sending rpc:s to your ext2 filesystem process. But there will *not* be any translator representing the unzipped data. Because that's done by a libstore module that is linked into your ext2 process. As for hackability, if you have written your own store type, you can't force other people's processes use that, for instance, you can't tell the root filesystem "hey, I'd like you to use my new store". But if you run your own libstore-using processes, you can link them with any new store type you like, at link time or runtime. I think you could deal with ip-over-foo in an analogue way, where each foo is a new "if type" in "libif", or some such. This kind of modularization applies both to a "central" pfinet, and if you move networking code into the user processes. The more I think about it, the cooler the network-in-user-process model seems. A process that creates a socket would talk to one or more pfinets. Each pfinet offers a directory of interfaces. And if I bind to the wildcard interface, my process will simply open each interface, and ask for dir-notification on the directories so that it can pick up any new interfaces that show up. The hard problem in making this work is to define the interface-interface in such a way that different users can't mess up eachother's connections, allocate the same port numbers, etc. That's probably non-trivial. /Niels _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
