Alessandro.Forin@SPICE.CS.CMU.EDU (09/03/90)
The multiserver Mach 3.0 [and other systems such as Plan9, for instance] place indeed much more semantics in filesystem names. For networking, we have a Network Protocol Server (NP) that contains the protocol code and talks to the ether device (or whatever) at the packet level. It's NP's business what names mean. It's independent of the OS environment (streams, sockets whatever) what is the interface that NP exports to other servers and to the U*x emulation library. [Right now it's just the socket BSD interface, cuz we did it 2 years ago quickly just to see if the thing was plausible] What I am interested in for the second round implementation is what would be the most flexible interface for NP. The goal is to come up with something that can satisfy the needs of multiple OS environments [BSD, sysV, VMS, you name it]. What I have in mind right now is to just be concrete and go with something along the lines of BSD's protocol layer (underneath sockets). This assumes that streams can be made to work on top of it [which is, I gather, exactly what most SysV TCP implementations are]. We (CMU) are not interested in streams or sysV directly, but a number of other people certainly will. Comments and suggestions are therefore extremely welcome. As for extra functionality.. you certainly get to "see" what's going on under /net [default mount point for NP]. If I go by protocols, there are subdirs like /net/ip (maybe /net/arp) /net/iso /net/ns , and then /net/ip/tcp /net/ip/udp /net/ip/imp and so on. What's under each protocol is fuzzy, right now, but it will let you see all established connections. As for 'manipulating' things there.. Keith Sklower and others have already pointed out that 'creat' might be messy, but opening an existing file, reading and writing to it (permissions aside) is doable, just like named pipes. [In other words, new names are only created by NP as part of the connection setup] I would pose that /net/<some host name>/<blah> loses because a given host can only be reached via some other qualifier besides its 'name': both ether address(es!) and IP numbers are ok, for instance, if you use the right mean. Then again one could overload symlinks to get a different view into the name space. In our system each and every system or user server can export a name space: I can think of the existing named and inetd as simple and useful cases of U*x network servers that can be extended this way. And BTW, all the various databases that go with a server can be administrated in a simpler way by collecting all permanent and temporary information within the server's subtree. Sooo, you have a chance to voice for a bigger-and-better network system .... shoot! sandro- Historical note: We already have a remote filesystem (RFS, it was born long before ma Bell's one) that works along these lines: /../somehost/usr/ is the /usr directory in host's <somehost> namespace. This is where our own ideas originated.
bzs@WORLD.STD.COM (Barry Shein) (09/04/90)
The issue of name server resolution and similar problems was raised by
Robert Elz. This is a real problem and well worth grappling with.
What has been done in various special-case forms but has never really
been standardized into unix kernels is a clean interface which allows
the kernel to call back out to a user process for information.
For example, one simplistic approach would be a daemon which registers
a service with the kernel (similar to bind() in philosophy) and then
waits for requests.
This could be cobbled up as a socket thing, call it the UNIX_KERNEL
protocol. That would, for example, allow the current name service to
do this via just adding another fd to its select() call:
daemon:
struct sockaddr_kern sockk;
sockk.port = NAME_SERVICE;
skern = socket(KERNEL,SOCK_DGRAM,0);
bind(skern,&sockk,sizeof(sockk));
...etc...(select/accept loop)
PDP-10 types will of course recognize this as a generalization of the
ACJ idea. And it could very well be used for authorization etc.,
anything where it would be nice to manage various data at user level
and let the kernel just query these user processes for things like
"can this uid do remote TCP connects?", "what does this string
translate to?", "user foo's job just ran out of memory, please log to
a file".
Current facilities, such as kernel error logging, could be completely
replaced by this sort of facility.
I'm sure people will now tell me that XYZ is just this, I'm
interested, but I suspect what we'll find is a lot of little special
facilities that never quite got generalized, or have some other
strange limitations.
Of course, generalizing this so the query relays to another server
over the net is almost trivial (the user level daemon can do that, and
in the case of a name service almost certainly would.)
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD