Hi, On Sat, Mar 29, 2008 at 05:04:48PM +0100, Carl Fredrik Hammar wrote:
> > /ip/eth0/tcp/ /ip/eth0/udp/ /ip/eth1/tcp/ /ip/eth1/udp/ /ip/lo/tcp/ > > /ip/lo/udp/ /ip/tcp/ /ip/udp/ [...] > Shouldn't it be /eth0/ip/tcp/? I.e. with internet protocol is layered > over ethernet. Indeed, the more I think about it, the more I get convinced that you are right :-) There are some things to keep in mind though. When /ip is the top level, it can naturally serve as a master translator/multiplexer, managing the other nodes. With the device directories at the top, the question arises how to handle them... The simplest (but least elegant) approach would be simply to create static directories for each available device; and whenever an IP translator is attached, tell it the device explicetily. (settrans /net/eth0/ip /hurd/ip -d eth0) Another approach would be to have a rather dumb device translator, which tells the attached nodes what device to use, so it needn't be passed explicitely. Ideally, the device translator would actually sit between the kernel device and the clients, managing access... But I wouldn't consider that part of the IP stack task. (Actually someone was working on a BPF translator in the past, but it wasn't finished :-( ) A second question is how to handle listening on all available interfaces. (I think the socket interface allows for that?) A top-level ip translator could manage that in a natural way; with the devices at the top level, we need some additional facility to keep track of all available interfaces. It shouldn't be hard, but needs to be taken into account. > In any case, I'm not sure why you have chosen directories. Why not > just: eth0, eth1, ip0, ip1, tcp0, tcp1, tcp0+1 etc. where tcp0+1 works > like your /ip/tcp/? First of all, I hope you didn't mean to imply that the numbers in ip0 and tcp0 correspond to that in eth0... Because that would be plain wrong :-) lo for example has no number at all; while we could have both eth0 and ppp0 for example. So, if we want to enumerate the ip interfaces like that, the enumeration will be completely independant of the device names. But is it really useful to have such an enumeration at all? I think the socket interface doesn't use anything like that; interfaces are selected either by device name or by IP... (Correct me if I'm wrong.) And I don't see any reason to do different with the filesystem-based interface. The '+' syntax for listening on multiple devices looks interesting. I wonder though how useful it is. Does the socket interface provide a possibility for listening on multiple but not all devices? If not, is is useful to add such an ability?... In any case, we still need a way to specify the '*' case without listing all individual devices, I think. As for flattening the hierarchy, I'm very sceptical about that. True, it would simplify things: You could just have all the nodes in a normal directory for example, statically set up with passive translators; everything could be done with simple single-node translators. This is pretty ugly, though. It means that all the relations always have to be specified explicitely, e.g. "settrans /net/tcp0 /hurd/tcp /net/ip0". Also, it means a totally static setup. Instead of a normal directory, some kind of translator (multiplexer) could be used to manage all the nodes in /net. It could be more dynamic, and manage the associations between the nodes automatically. That would be very intransparent though; and it would destroy much of the decentralization and flexibility possible with the modular stack... With a directory tree on the other hand, the structure is expressed in a very natural, intuitive manner. But it's more work: First of all, it requires coming up with a good directory structure. Then the implementation is more complicated, as each layer has to export a directory with child nodes. And the setup gets more tricky: We don't have a normal directory anymore, where we could store all the nodes as passive translators; rather, the nodes are attached to virtual filesystems exported by the lower layers... One way would be for the virtual directories exported at each layer actually to allow storing ordinary passive translators. Of course, that would be very static again... Alternatively, each layer could launch the translators for the nodes it hosts, i.e. serve as a multiplexer. This is actually similar to hosting passive translators, except that the configuration (what to launch and when) would use some different, custom mechanism -- it would be more dynamic than passive translators, but less transparent. Yet another approach would be to leave the underlying translators out of the setup completely, and instead just set active translators for all nodes explicitely, using a script run when setting up the network interface. At least part of it probably could be even done by the clients themself upon demand -- the socket wrapper could do that transparently, while clients using the filesystem interface directly would have to do it explicitely. This setup question is a fundamental problem which we need to solve, not only for the network stack, but in general when we start using translators more extensively... Perhaps namespace-based translator selection can be useful here, once it is available: It would avoid explicitely setting translators alltogether, and instead one could for example just access /net/eth0/ip,,tcp to open a tcp connection on eth0. Problem with this approach is that it's not very transparent: Translated pseudo-nodes can be opened on demand, but don't show up in a directory listing... -antrik-
