From draken!kth!enea!mcvax!uunet!tektronix!orca!tekecs!frip!andrew Sun Oct 9 00:57:37 MET 1988 Article 10488 of comp.unix.wizards: Path: liuida!draken!kth!enea!mcvax!uunet!tektronix!orca!tekecs!frip!andrew >From: andrew@frip.gwd.tek.com (Andrew Klossner) Newsgroups: comp.unix.wizards Subject: More notes from V.4.0 software developer conference (LONG) Message-ID: <10421@tekecs.TEK.COM> Date: 4 Oct 88 20:37:18 GMT Sender: andrew@tekecs.TEK.COM Organization: Tektronix, Wilsonville, Oregon Lines: 407 I attended the UNIX V.4.0 conference in Los Angeles. Herewith some highlights from my trip report. OVERALL IMPRESSIONS UNIX V.4.0 really is all things to all people, and AT&T is working hard to make it that way. If a program worked under V.3, or under Xenix, or under SunOS, or under 4.3BSD, it will work here. PHILOSOPHIES The philosophy of the V.4.0 source tape is that it provides a "menu" of software, and it's up to the OEM to select a subset (within the constraints of the SVID). AT&T hopes that the market will narrow down to a core set of features/utilities, so they can slough off the remainder (e.g., they'd like to discard one of the three shells). We found out what an "open system" is. An "open system" is a closed system. Here's why: AT&T defines an open system to be the opposite of a proprietary system. Proprietary systems come from one vendor and run on one architecture. Open systems run on many architectures and are supported by many vendors. The advantage of an open system is that an application will run, without much modification, on each architecture. Therefore it is important that the open system not be changed significantly between architectures. Therefore an open system is substantially closed to the OEM. This closure is expressed in the language of the infamous UNIX V.3 license, which requires that any derivation of V.3 conform to the System V Interface Definition (SVID), a Levitican document. However, the above notwithstanding, AT&T seems to be looking for industry comment on several aspects of V.4.0 now, before it is cast in concrete. In particular, they want comment on the draft ABI and on the draft Open Look spec. UNIX UNIFICATION V.4 includes not quite all of 4.3BSD. Little things, like biff and sendmail, are missing. The porting base for V.4 will continue to be the 3B2. Presumably there will also be a 386 source tape, as there is for V.3.2. No word on a SPARC tape. VIRTUAL MEMORY V.3-style shared memory is discarded in favor of Berkeley/SunOS-style shared memory. V.3-style shared memory calls are implemented with a compatibility library. In addition, it will support mapped files, even across the net. FILE SYSTEMS AND I/O V.4 will support both the Berkeley Fast File System, now called "ufs," and the standard AT&T file system, called "s5." Ufs is the default. Ufs has long filenames, s5 has the usual 14-character filenames. All file systems now have symbolic links. The Berkeley dump/restore programs are there but they work only on ufs. Quotas work only on ufs. A process can have up to 2048 files open. To exceed 64, the process must call setrlimit to raise the "soft limit." Stdio supports up to 256 open files. Root can exceed 2048. File descriptors are "cheaper" -- dynamically allocated/freed from kernel memory. The buffer pool "has been re-architected." No details. But, since the results of file I/O on mmap'ed files are immediately visible to the mapping process, presumably paging still goes through the buffer pool. The directory layout will look like that of SunOS. No more /bin. DEVICES All tty devices are Streams devices. Ptys are also Streams based. There will be standard Stream modules to implement the favorite tty line disciplines: "LDTERM" for V.3, something else for Berkeley "new tty." Pipes are implemented as Streams. Named pipes are implemented as named Streams (a new feature). The names are in the file system space. They seem to have repudiated the terrible V.3 philosophy of establishing an independent name space for each new construct. The poll system call (like Berkeley select) works on non-Streams file descriptors. For character devices, this requires a mod to each driver. They didn't explain just what poll does on files and directories. The "CONLD" Stream module creates a unique Stream on open. It's used for pipes only. A client process could open a particular file and find itself talking on a dedicated Stream to a server, a nice simple mechanism. SIGNALS The system will support three different signal abstractions (!): the V.3 one, the Berkeley one, and the POSIX one. AT&T recommends that new code use the POSIX one; the other two are built on top of it. SHELLS Korn shell and C-shell will come standard on the tape, along with the Bourne shell. The kernel will be able to exec shell scripts which begin with "#!". The setuid/setgid bits for such files will be ignored. LANGUAGE SUPPORT AND DEBUGGERS Any C compiler provided with V.4 must implement both ANSI C and some AT&T-defined extensions. It must also be able to produce position-independent code, because those libraries can be mapped to any virtual address that the mapping process chooses. An ELF (the new object file format) manipulation library will be provided. A process filesystem, /proc, is standard. The debuggers have been reworked to use it instead of the ptrace system call, which will be phased out. Adb and gprof will be in the Berkeley compatibility package. There will be no dbx. Sdb will be "enhanced." Truss (an interesting debug tool) is standard. LIBRARIES Shared libraries are now dynamically-linked, to addresses chosen by the main program. This means that shared libraries must use only position-independent code, which means that the compiler must generate PIC. Static libraries are still there but are being phased out. "Message management" has been added. The user can select a format for error messages by setting environment variables. If all components of a message are turned on, the message can occupy several lines, and the information can include who was running, what operation was attempted, why it failed, and what the suggested fix is. The message formatting facility is still open for "industry review." It is part, but not all, of an effort to provide easy conversion of applications to use foreign languages in messages, with the language chosen dynamically. Not all utilities in V.4.0 will be converted to use it. REAL-TIME SUPPORT Real-time support is as follows: kernel code that contributes to long latencies has been filled with preemption points. At each such point, the kernel checks to see if a real-time event needs to be handled, and, if so, the current process goes to sleep and the scheduler is called to start the process that gets the event. NETWORKING There is full socket support, including UNIX-domain sockets. Sockets are implemented on top of Streams. They are a peer to TLI (transport level interface), they are not on top of TLI. r* (rlogin, rsh, etc) commands are still built with sockets. TCP/UDP/IP is the only transport provider on the V.4.0 tape. No OSI code yet. V.4.0 includes SMTP. "Mail has been completely re-architected." DES authentication cannot be removed from RPC. They claim "there is an export license." YP (NFS yellow pages) is considered deficient and will be revised after V.4.0. There is a new network line printer spooling mechanism, an extension of the V.3 "lp" package. "RFS and NFS are complementary." The philosophy is that NFS is for heterogenous file sharing (talking to MSDOS and Cray computers), and RFS is for intra-UNIX machines when full file system semantics are needed (including talking to remote devices). They said all this with a perfectly straight face. RFS communicants must have the same byte-order, alignment, etc. in order to use remote devices. RFS symlinks are interpreted local to the client, just as NFS symlinks are. This is "being discussed." (The now-obsolete Tektronix network file system interprets symlinks local to the host, and our customers are giving us grief about the "new" NFS semantics.) Diskless node support is said to be easy to do, although it doesn't come already done on the V.4.0 tape. It uses TFTP, reverse-ARP, and NFS. RFS allows UID mapping. NFS doesn't, except for root. Both NFS and RFS can be used to page across the net. Any file system node can be mounted. For example, you could mount remote:/bin even if /bin is not a separate file system on remote. CHARACTER WINDOW SYSTEMS Curses has been extended; it can now deal with colors. However, it cannot deal with SIGWINCH. It was implied that vi would not deal with SIGWINCH, but that's counter-intuitive since the Berkeley version does (and doesn't rely on curses). ETI, the "extended terminal interface," is a window toolkit for character ttys. It's built on top of curses, but allows for overlapping windows, sort of. FMLI, the "Form and Menu Language Interpreter," is an interpreted language in which character tty windowing programs are written. It has a standard look&feel, that isn't anything like Open Look. It's built on top of curses. The language design itself is hideously bad, reminiscent of IBM JCL. The new sysadm (system administration) is written in FMLI, so it uses curses and menus etc. (The V.3 sysadm assumed a dumb tty.) FACE, the "Framed Access Command Environment," is ... well, I'm not sure what it is. It might be a windowed shell for character ttys. It's built on top of either ETI or FMLI. GRAPHICAL WINDOW SYSTEMS The Open Look Graphical User Interface is a document, not software. There will be software to implement it, but it's the document that they're pushing right now. The Open Look window "shine mark" was inspired by cartoonists. Open Look windows seem to waste a lot of precious screen space: title, header, footer, extra border past the scrollbar. Yech. To direct keyboard input to a different window, it is necessary both to mouse to the window and to click a mouse button. (Under X, the button click is not needed.) There were hints that this might be true only under the NeWS implementation of Open Look. In an Open Look window, selected text does not include white space past EOL. In X's xterm, it does. I prefer xterm's design. Inaccessible menu items don't appear at all. In the xterm/Macintosh model, they appear but in halftone (gray letters instead of black). I find the Macintosh approach a lot less confusing; it saves the naive user from hunting about for the menu item that "I know is there somewhere." Exclusive/non-exclusive items are not well differentiated. Exclusive items are those from which exactly one can be selected (e.g., bold/italic/normal font). Non-exclusive items are independent (e.g., jump scroll/reverse video/autowrap). Exclusive items appear in contiguous horizontal boxes; non-exclusive items are in boxes separated by a bit of white space. The currently-selected item is displayed in boldface. The whole notion of separating menu items with horizontal instead of vertical distance I found ugly. Sigh. Scrolling warps the cursor. This is awful -- you should never warp the cursor! On the plus side, "notice" windows are great. If you select a menu button which causes the system to request confirmation (e.g., deleting a write-locked file), a notice window "grows" out of the screen from that button: +--------+ |warning |\ |file is |\ |r/o | \ +--------+ \ \ \ \ \ (It looks much better than this poor pictorial attempt.) The perspective lines converge at the menu button which gave rise to the notice, so the user knows why the notice happened. Another good design feature is the built-in help function that assists the user in learning about Open Look. To request information about a feature, you designate a widget (e.g., the scrollbar), and the help screen includes an image of a window with a magnifying class over that widget to let you know what it's describing. Very intuitive. And everybody likes the push-pin widget (used to keep a menu window from disappearing). V.4 includes a window manager (which manages both X and NeWS windows), an X terminal emulator, a NeWS terminal emulator, and a desktop (but they're not sure if the desktop code is on the tape). None of this stuff seems very far along. The prototype software they showed us, a text editor, was apparently hacked together on top of an existing window package. This is GOOD, of course; you want to get experience with a new look&feel before committing to a lot of software development. It was interesting that, when someone asked the presenter how the prototype had been written, his only answer was that it didn't matter, all he wanted to discuss was the look&feel. He refused to give prototype implementation details. They don't know or haven't decided whether Open Look widgets will be donated to MIT for addition to the X software base. The NeWS application level supports object-oriented programming in C++. They don't know whether any GKS or Phigs support will be done, which means it probably won't. ABI (APPLICATION BINARY INTERFACE) There is no plan to make an ABI for the 3B2 (the WE32000 architecture). The only standard media for application packaging defined in the ABI are 3.5" floppy and 120M cartridge tape. It was noted that neither of these are available on the 3B2 series. This is generic, not architecture-specific: these two devices will be the only choice for all ABIs. They are "looking for industry comment" on this. The system interface routine library *must* be dynamically linked; the method by which the syscall library routines call the kernel is NOT specified by the ABI and may be changed by the OEM. AT&T is focusing now on the generic portion of the ABI, getting it "right." V.4.0 has Extended Fundamental Types (EFT). Type widths will be architecture-specific, i.e., it's up to the architecture-specific portion of each ABI whether that architecture will have EFT. LICENSING ISSUES [The license expert missed his plane, so a non-expert handwaved his way through this presentation.] A UNIX-tm must be a derivative of V.3.2. You can cobble up something that conforms to the SVID without using UNIX code (and without having to pay UNIX license fees), but to make something that's eligible for the UNIX trademark, you have to start with genuine UNIX. A UNIX-tm must conform to (as yet unspecified) quality standards. Perhaps auditing procedures. The status of machine-readable man pages is "in dispute." Any UNIX license questions should be directed to (800) 828-UNIX. BIBLIOGRAPHY They sent home enough documentation that the handle broke off my suitcase. This included all the overhead slides, and, with each slide, up to a page of explanatory text. Outstanding! The Software Developer Conferences, Volume 1: -- The Worldwide Open Industry Standard (why open software is good) -- Basic Operating System Services (files, VM, etc) -- Applications Development Environment (C language and software generation system changes) -- Networking The Software Developer Conferences, Volume 2: -- User Interfaces (both character and graphic) -- Enhanced System Administration -- Application Binary Interfaces (discussion of) -- Continued Commitment to Open Standards -- Future Plans -- Licensing -- Glossary and Index -- Further Information: available manuals and courses; speaker bibliographies A copy of the SVID, edition 2 (describes V.3). A draft of edition 3, which describes V.4, will be distributed eventually for industry comment. OPEN LOOK X User Environment Application Programmer's Interface -- everything the X programmer needs to use the (not yet available) Open Look X toolkit. 100 pages. OPEN LOOK (tm) Graphical User Interface Functional Specification, dated July 15, 1988. About 150 pages. AT&T Character User Interface Style Guide -- discusses ETI, FMLI, FACE, other aspects of character-tty windowing software. About 100 pages. System V Application Binary Interface (ABI): Draft for Industry Review, dated August 31, 1988. The cover letter says that industry comments must be in by Halloween. About 200 pages. "Migration Reference Guides" for SunOS (20 pages), XENIX (50 pages), and UNIX V.3 (100 pages). To be used by an application developer coming from one of those environments into V.4; it addresses porting/transition questions. Another such guide is promised for Berkeley. Software Developer Conference Bulletin Board System. They've established a bulletin board system in New Jersey with a 1200 baud line, to be used for getting information about and asking questions about V.4.0. [Don't ask me for access details, I don't believe I'm allowed to divulge this ... go to a conference or call AT&T directly.] -=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP] (andrew%tekecs.tek.com@relay.cs.net) [ARPA]