slogin: THE UNIX NEWSLETTER Volume 5 Number 10 December 1980 CONTENTS Guidelines for Submission of Newsletter Material......- Sheva jiei's: $9 wide a elon 1 Editorial ccccccccnrecsccrecsccccscccreseercesscenseereseeensesesrscnees 2 Cromemco's CROMIX Operating Systems... cece ncse rece cecewnecsceeencens 3 UniFLEX Operating System..... cc ccce cece nsec cee see en seceeseesscesesseee 5 Notice This newsletter may contain information covered by one or more licenses, copyrights, and non-disclosure agreements. Permission to copy without fee all or part of this material is granted only to Institutional Members of the Usenix Association provided that copies are made for internal use at the member campus or plant site, * UNIX is a trademark of Bell Laboratories Guidelines for Submission of Newsletter Material I would like to use the modern text preparation and communications facilities of UNIX to as great an extent as feasible in the preparation of the Newsletter. I have established an account on our PWB/UNIX system so that those who can provide us with machine manageable material can do so. The telephone number is (512) &74-5511. The login name is login and the password is usenix. (The system is also host utexas-11 on the ARPANET. ) For those submitting paper copy of material, please produce your copy on a daisy wheel printer or similar high quality printing device. Line printer produced copy is typically not adequate for reproduction. Copy should be on 8 1/2" by 11" paper with a 1" margin on left, right, and bot- tom and 1 1/2" margin on top. U. S. Mail submissions should be addressed to: Login Newsletter Computation Center The University of Texas Austin, Tx 78712 Attn: Wally Wedel December 1980 2 slogin: Editorial This issue of the newsletter carries two articles describing two of the "UNIX-like" systems available for micro-processor based computer sys— tems. These articles were developed from material supplied by the vendors and from conversations with representatives of the vendor. The emergence of these systems and others sure to follow raise some interesting and potentially disturbing questions. One such question is: What do we mean by the term "UNIX-like"? There seem to me to be three fairly distinct levels from which "UNIX- likeness" can be described. The first of these is the operating system command and response language (OSCRL) level (UNIX users read "shell"). The second level is the available utilities for the system under discussion. The third level is the program interface to the operatirg system (system calls). Level one defines a major portion of the user's view of the system. This level includes shell program statements, i/o redirection, and notation for specifying concurrent processing with interprocess communication. Level two describes products available under the system. Is there a familiar editor? What languages are available? Does the system provide text processing facilities comparable to those of UNIX? Are the utilities known by the same name as under UNIX? Do the utilities which carry the Same name as under UNIX work’ the same way? Are the parameters of the util- ities comparable to those of UNIX? Level three describes the program level interface. It assumes the existence of a reasonable high level programming language such as C or Pas— cal. Major questions here include 1) Do system calls named the same as those for UNIX behave the same way? 2) Are there additional calls to the system? UNIX or a look-alike? As many of us in the UNIX community know, the UNIX Programmer's Manual often does not cover fine points of the behavior of programs which run under UNIX. Systems which carry over most of the source code of the UNIX kernel and its utilities would seem to have the best chance of looking to users like a real UNIX. Those systems written from scratch to the specifi- cations of the UNIX Programmer's Manual would seem to stand a gocd chance of not working "right" to an experienced UNIX user unles: the code was developed by an experienced UNIX user. Current UNIX licensing procedures make it difficult to easily distin- guish between systems based on a high percentage of UNIX Bell Labs and sys- tems developed from the UNIX Programmer's Manual. December 1980 3 slogin: Cromemco's CROMIX operating system It is an interesting commentary on Cromemco's view of their industry that when the time came for them to consider a multi-user operating system for their line of micro-computers they turned to the UNIX model. The system they have developed should be easy for a UNIX user to learn to use. The shell command level lacks a pipe operator but otherwise looks a lot like a real shell. Many of the major UNIX functional capabilities are available under CROMIX but often with different names because they perform dif- ferently. The ‘System call xevel appears to be well d2fined with most of the necessary UNIX-like functions. A compatiblity module for their single user system, CDOS, is provided under CROMIX, A major incompatability between the current version of CROMIX and UNIX is the lack of an interprocess communications facility (pipes). Rumor has it that this omission will be corrected shortly. CROMIX uses the Z80. bank switching capability to allocate memory. Currently each process is allocated a 64k byte bank of memory with CROMIX itself occupying bank 0. Consequently, the minimum amount of memory required for a single process system is two banks or 128k bytes. This is a potential confining feature of CROMIX for many UNIX users who often gen- erate multiple processes without even being aware of it. Since many processes do not occupy anywhere near 64k bytes it would appear that a scheme for permitting multiple processes to reside in a single bank of memory would be desirable as a future enhancement if it could be obtained at relatively low cost. The CROMIX file system structure will appear very familiar to UNIX users. The file and directory naming conventions will also be recognizable by veteran UNIX users. The ASCII caret (7) has been introduced to refer to the ancestor directory of the current directory. (i.e. instead of ../file you say “file to reference a file in the parent directory). File protections have been modified slightly to include an append only mode in addition to the other file access modes of UNIX. Utilities Since no CROMIX Users Manual has been made available to me, no assessment of the available shell commands can be presented here. System Calls An important aspect of the UNIX-like property of an operating system is the nature of modifications to programs written for UNIX so that they will run on the target system. CROMIX actually does quite well in this regard. The designers have taken care to make sure that the names of system calls are changed where a system call is not compatible with UNIX. Most of the important system calls appear to be available in UNIX form or in an extended form. The pipe calls are an obvious omission. December 1980 4 slogin: Implementation CROMEMCO took the interesting approach of doing the operating system in assembler and then developing a C compiler. It is to be hoped that subse- quent implementations can be done with CROMEMCO C. Whether that ever comes about depends to a great extent on the quality of the code produced by their C compiler. CROMIX System Functions close(fn) - Close a file. creat(fname, pmode) - Create a file. lseek(fn, offset, origin) - Position file pointer. open(fname, rwmode) - Open a file. read(fn, buf, n) — Read from a file. write(fn, buf, n) ~ Write to a file. ecdos(z80regs) - Execute CDOS system call. ecromix(SYSCALL, z80regs) ~ Execute CROMIX system call. exit(status) -— Abort program. system(string) - Fork a shell and execute string. eaccess(channel) ~ Test channel access. echstat(channel, statustype, statusvalue, statusmask) - Change channel access privileges, chdup(channel) = Duplicates a channel. chkdev(dtype, dmumber) - Checks for the presence of a device driver. elink(channel, pathname) - Establishes a link to an open file. elose(fn) — Close a file. create(filename, accessmode, accessmask) - Creates and opens a new file. estat(channel, statustype, inodebuffer) - Determine status of open file. delete(filename) - Delete a file. error(errno, channel) - Display error message. exec(argv, pathname) — Executes a program. exit(status) - Abort a program. faccess(pathname) ~ Tests file access. fchstat(pathname, statustype, Statusvalue, statusmask) - Change status of file. fexec(chmask, argv, pathname) - Forks and executes a program. flink(pathname, newpathname) - Establishes a link to a file. fshell(argv) — Forks a shell process. fstat(pathname, statustype, inodebuffer) - Determine file status. getdate(date) - Gets the date. getdir(buffer) - Get pathname of current directory. getgroup(idtype) - Gets the group id. getmode(channel, modenumber) ~ Gets the characteristics of a console device, getpos(channel) - Get value of file pointer. getproc() — Get the process id. gettime(time) — Gets the time. getuser(idtype) - Gets the user id. indirect -— Identical to ccromix. makdev(pathname) - Create a new name for device. makdir(pathname) - Create a new directory. mount(dummypath, devpath, access) - Enables access to a file system. December 1980 5 login: UniFLEX Operating System The UniFLEX* Operating System is a state of the art operating system for microcomputers. The system's design has been influenced primarily by two other operating systems, FLEX and UNIX. UniFLEX retains the flexibility and ease of use of FLEX while incorporating some of the widely accepted structures of UNIX. UniFLEX is a true multi-tasking, multi-user operating system. Each user communicates with the system through a terminal and may execute any of the available system programs. Each user must 'log in! before being permitted to use the system. Tne log in process requires the user to enter his user name, followed by a pass— word. ‘The system checks the validity of the password, and if accepted, the system command language program is run. Full system accounting is sup- ported by UniFLEX which will keep track of user log-in and log-out times, as well as the user's utilization of system resources. UniFLEX is a very complete operating system and has no practical limita- tions built into the software, almost all of them are hardware imposed. It supports a hierarchical file system allowing file sizes up to one billion bytes and disk capacities of over eight billion bytes. All files are fully protected. A user may read, write, or execute protect files on an indivi- dual basis. All system I/O is device independent since I/O devices may be attached to the system. A sample system configuration might have a ninety megabyte disk, a thirty megabyte disk, two eight inch floppies, a parallel driven printer, and nine user terminals. Any running task may initiate another task in an asynchronous manner. Inter-task communication is also supported. Task swapping may take place on those systems incorporating an appropriate swapping device. In real time applications, where swapping may be detrimental, it is possible to lock a task in main memory. The user's main connection with the system is through the command language, the shell. This is the vehicle for inputting commands to the system. It supports a wide variety of features including parameter passing and various types of name pattern matching. Input to the command language may be from the ter- minal or from any file (including other devices). The overall design of UniFLEX is geared toward the larger microcomputer systems. UniFLEX will be for the upcoming generation of microcomputers which support massive amounts of main and secondary memory. Not only is the 6809 supported with this system, but support of future 68000 based machines will be supported. Hardware Requirements UniFLEX requires a system based on either the 6809 or 68000. The mainframe must support extended addressing (a minimum of 19 address lines) and some form of memory segment management. The memory mapper must have the minimum must have the minimum ability of mapping memory segments no larger than 4K, anywhere in the cpu address space. The operating system will support * UniFLEX and FLEX are trademarks of Technical Systems Consultants, Inc. December 1980 6 login: multiple mapping registers as well as hardware memory protection schemes although neither 1s a requirement, A minimum of 96K of memory is required. The operating system code resides in less than 14K of memory, but in order to support all of the system's features, such as system accounting, automatic login, and multiple user tasks, the 96K is strongly recommended as a minimun. All system 1/0 devices must be interrupt driven. Terminals may be run either from separate ACIA type controllers or through an I/O buffer proces- sor, At least one eight inch, single density floppy disk drive capable of supporting 512 byte soft sectors must be supported. The drive must be interfaced with a DMA, interrupt producing controller. This drive will be used for program transportation and system booting. Any other disk con- trollers may be added to the system but they should be of the DMA variety and support 512 byte blocks. System Support The basic UniFLEX system includes the operating system, about 50 system utilities, a text editor, macro assembler, and system configuration pro- grams. Systems maintenance is available. There is currently a wide variety of support software available or in the development stages to run under UniFLEX. These include a C compiler, Pas- cal, Text Processing system, a debug package, and BASIC incremental com- piler which is compatible with out Extended BASIC. It should be noted that both the C and Pascal compilers will produce assembler language output which will yield much more efficient systems than others which produce an intermediate code (such as P-Code)} which must be interpreted. Many other programs are being considered, including FORTRAN, RPG/11, and a data base management system. Operating System Calls UniFLEX supports a wide variety of system calls. These deal with file management, task management, and general system maintenance. A partial list of calls will be given here along with a brief description of each. December 1980 7 slogin: UniFLEX System Calls File managing and i/o calls open(pathname,mode) - Open a file for read or write or both create(pathname,permission) - Create a new file and open it for write read(filenumber,address,count) ~ Read from a file write(frilenumber,address,count) - Write to a file seek(filenumber ,offset,type) — Position file pointer close(filenumber) ~ Close a file dup(filenumber) ~ Duplicate an open file dups(filenumber ,specifiednumber) - Duplicate a specified file chown (pathname ,newowner) ~ Change the file owner chprm(pathname,permission) - Change file access permission chace(pathname,permission) - Check file access permission defacc(permission) - Set default file access permission link(oldpathname,newpathname) — Link to an existing file unlink(pathname) - Unlink from a file (delete) maksd(pathname,permission,special) - Make a special directory type file chdir(pathname) - Change working directory ofstat(filenumber,buffer) -— Get an opened file's status status(pathname,buffer) - Get a file's status mount(devicepathname ,pathname,mode) ~ Mount a device on the system unmnt (devicepathname) ~ Unmount a device Tasks management calls exec(pathname,arglist) ~ Execute a new program fork() - For a new task wait() - Wait for a forked task to complete term(status) - Terminate a task epint(interruptnumber,address) — Catch a program interrupt spint(tasknumber,interruptnumber) - Send a program interrupt gtid() « Get the task id guid() - Get the user id suid(newuserid) ~ Set the user id setpr(priority) - Set running priority bias The Usenix Association PURPOSE: The Usenix Association is an organization of Western Elec- tric licensees and sub-licensees formed for the purpose of exchanging information and ideas about the UNIX operating system and the C Progamming Language. MEMBERSHIP: Four classes of membership in Usenix are offered: 1. Institutional Membership. Institutional Members are the voting members of the Usenix Association. This class of membership is open only to licensees or sub- licensees of Western Electric Co. 2. Non=-voting Institutional Membership. This class of membership is open to corporate affiliates of AT&T. 3. Individual Membership. Open to employees of class 1 and 2 members and others who are bound by the software agreements with Western Electric and its licensees. - 4, Public Membership. Open to anyone with a bona fide interest in the purpose of the Usenix Association. For further information write: Usenix Association Rockefeller University Box 8 1230 York Avenue New York, New York 10021 (212) 360-1182 Facts about UNIX and the Programming Language C The UNIX operating system was developed by Ken Thompson and Dennis Ritchie of Bell Laboratories in Murray Hill, N.H., during the early 1970's. The C Programming Language was developed originally by Thompson and Ritchie as the implementation language for UNIX. UNIX is made available to the public by Western Electric Co. through its patent licensing office in Greensboro, North Carolina, A fine overview of UNIX and C was published in the Bell System Technical Journal, Vol. 57, No.6; Part 2, in August 1978. The C Programming Language is described in the book The C Programming Language by Brian Kernighan and Dennis Ritchie published in 1978 by Prentice Hall.