Hey, I did some reading up on the Plan9 design for their network hierarchy. I think it's interesting. I wouldn't mind using it just so the layout would be more commonplace (for those who may have used Plan9). I also like the access to the interface statistics. Plan9, from what I've read, tries to abstract the interfaces to look the same to the client, which seems a little abstract to me if a client is going to control the data structures. It might be the opposite of what the client wants. IMHO, I think the client should be smart enough to choose the interface it wants as I don't think that's a real hurdle for developers.
I heard the deadline was extended by a week by someone on the GIMP developer list and that it would be updated on Google's timeline for SoC. However, I have not seen this change so I am assuming today is in fact the last day. I am going to try to organize my last few ideas for the project layout today before the closing period, but they'll be just ideas since it seems several of the Hurd developers have provided a lot of different ideas for the actual file structure they would like to see. I do like the Plan9 approach, but I'm not sure if a "transparent" interface is really what the Hurd group would want. Thanks, Josh On Sun, Mar 30, 2008 at 4:51 PM, <[EMAIL PROTECTED]> wrote: > 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- > > >
