Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Computers for users not programmers Message-ID: Date: 8 Feb 91 18:52:37 GMT References: <409@bria> <13252@lanl.gov> <27A97D37.4346@tct.uucp> <20752:Feb714:42:0891@kramden.acf.nyu.edu> Sender: cho@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 159 Nntp-Posting-Host: teacho In-reply-to: brnstnd@kramden.acf.nyu.edu's message of 7 Feb 91 14:42:08 GMT On 7 Feb 91 14:42:08 GMT, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) said: brnstnd> Followups to alt.religion.computers, as this stuff shouldn't be brnstnd> diluting comp.arch. But this stuff should instead, because probably by mistake :-) a technical point on systems architecture is raised here. brnstnd> In article <27A97D37.4346@tct.uucp> chip@tct.uucp (Chip brnstnd> Salzenberg) writes: chip> According to jlg@lanl.gov (Jim Giles): jlg> ... reconnect ... chip> These are *kernel* features, unrelated to the UNIX tool philosophy. chip> (Though they can sometimes be emulated incompletely; Dan Berstein's chip> pty tool allows reconnection after hangup.) brnstnd> Actually, to give credit where credit is due, Steve Bellovin brnstnd> designed the UNIX session manager, and pty's session management brnstnd> facilities are only slightly more general. The session manager brnstnd> provides reconnection facilities more powerful than in VMS or brnstnd> any other widely used operating system. I agree with the claim, but let me make a plug for Screen by Laumann which is another thingie that allows reconnection and does session management. I am just a satisfied customer. brnstnd> I disagree with Chip's statement that reconnect is a kernel brnstnd> feature; the fact that it can be implemented at the user level brnstnd> is a perfect example of the tool philosophy. Here is the architectural point: The layering of functionality between hardware, kernel, and user process is the essence of architecture, as it defines the surfaces which we use for multiplexing things. Now, and this is another example of billjoysm versus engineering, things like ptys, sockets and job control, that allow you to implement sessions management, are simply wrong, and they should be *neither* in the kernel nor in a tool. The fact that you *can* implement as a tool uner BSD, using incredible contortions, means that not all is lost, thankfully. But it remains true that the basic problem is that Unix does not have an architecturally sound uniform referent; file descriptors/pathnames are its main naming technology, and unfortunately the interface to a tty file descriptor is not the same as the interface to a file file descriptor or a pipe file descriptor. Ptys exist *only* to give you pipes that look like, on one end, ttys. Similarly job control. Also, the only way under traditional Unix to add new abstraction modules, type managers, has been to add device drivers. There are several remedies to these problems; some have been tried are: Edition > 7 or System V.4 or Plan 9 One uses streams (or STREAMS) as uniform referent throughout, that is file descriptors that can be flavoured dynamically in any way; so you can create a pipe and flavour it as a tty, obviating the need for specific pty code. Streams can lead to filesystems, which can provide objects with arbitrary semantics. You can do session management by adding a new filesystem type, one in which sessions are directories and processes in the session files under it, for example. 4BSD The original design of BSD was pure billjoysm. The final design was heavily influenced I guess by some capability man at UCB (easy to name!), and less billjoyist. "wrappers" were introduced in the design, which were to be software modules that would convert one flavour of file descriptor (e.g. pipe or socket) to another (e.g. tty). Not exactly similar to stream modules, but close. "user domains" were introduced to provide for the definition of new type managers as suer processes defining new socket protcol families. Neither feature has ever been implemented, I surmise because both attempted to paper over fundamental problems of disuniformity and would have required an excessively convoluted implementation. In the currently implemented crippled BSD we have one must use a plethora of servers and hacks like ptys. Accent/Mach In accent the uniform referent is the port, or software IPC capability, which is used throughout. Since user processes can create and distribute new ports to other processes, any process can become a type server (both streams and the BSD Unix domain allow this, but it has been rarely exploited). This approach worked beautufilly and failed to become popular; Unix programmers seem to thrive on irregularity and ad-hoc'ism. Mach was reborn as a more Unix compatible, i.e. irregular, design, and it has succeded. MUSS A very clever and little known design. Again uniform referent is the port, like in Mach, even if a bit cruder naming structure is used. Literally everything in the system, including filesystems, processes, devices, can be accessed as a port (which can be given a symbolic name). All ports in a network are equally accessible, so two arbitrary processes, or devices, or whatever can communicate across machine boundaries. As a rule the machine that drives your terminal is not the machine where you create your processes and neither is the machine running the file server. When a message arrives on a port it contains in its header the originating port number. Each line you type at a terminal (which is seen within MUSS as a process) is sent as a message to some port whose name/number you have given to the terminal driver. For example, suppose you want to create a session with two shell processes; you would do something like (I use symbolic port names thoughout), if you are using terminal 'tty2' on machine 'd': ***M login/a # connect to proc 'login' on machine 'a' pcg [pass] shell pcg1/b # create shell process on 'b' called 'pcg1' created: pcg1/b # reply message from 'login/a' pcg [pass] shell pcg2/c # create shell process on 'c' called 'pcg2' created: pcg2/c # reply message from 'login/a' ***M pcg1/b # connect to process 'pcg1/b' host # send a command line to the shell on it b # reply to previous line ***M pcg2/c # switch to process 'pcg2/c' host # same command line to the shell in it c # reply to previous line ***M a *console # switch to the 'console' device port on 'a' Pls mount pcg033 on b # ask the operator to mount a tape on 'a' Tape mounted (OP) # operator replies after doing a '***M d *tty2' .... # further work ***M b pcg1 # switch back to 'b' 'pcg1' quit # terminate the process and go home At this point you have left 'pcg2/c' lying around; the next day from any terminal you can do '***M pcg/c' straight away and reconnect to it. There is no need for any code to create sockets, ptys, handle STOP and CONT signals; it is all free thanks to having chosen a clever *architectural* structure, one based on the 'everything is a process accessible as a port of exactly the same flavour everywhere' principle instead of 'many things are a file/file descriptor of which there are many different flavours'. MUSS is a bit crude (for example, little authentication is provided by default), and one can easily improve on it (hindsight!), but it is sound. It requires somebody with the talent and stubborness of Dan Bernstein or similar to write something like 'pty' which takes several hundred lines under BSD, but under MUSS anybody can achieve the same effect in no lines at all just because things have been designed right. Accent is not as simple as MUSS, but at least it is vastly more flexible than either mainstream Unix. I think there are two clear lessons here: it is much better to get your architecture right, and commercial success does not depend on it at all. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk