gwyn%brl-vld@sri-unix.UUCP (11/15/83)
From: Doug Gwyn (VLD/VMB) <gwyn@brl-vld> In order to handle the volume of inquiries, I am posting a description of the BRL UNIX System V user/programmer environment for 4.2BSD to the mailing list. This is not a commercial offering, it continues to evolve, and I hope that only people with a genuine need will ask for the package since I am not budgeted for software distribution. There is a chance that some 4.2BSD packaged system vendors or support organizations will eventually provide something like this package with full support. It would also be nice if the two main UNIX familes would stop diverging, at least at the user/programmer level. The basic idea of this package, which is in the public domain subject only to Western Electric UNIX System V licensing restrictions, is: The user/programmer on a 4.2BSD system who desires a UNIX System V environment sets his $PATH to something like: PATH=/usr/5bin:/bin:/usr/bin:/usr/ucb:/usr/local:. The directory /usr/5bin contains a rather complete set of UNIX System V utilities (SCCS, PWB/Graphics, and the usual programs); the language processors have been modified to find #include files in /usr/include5 and libraries in /usr/5lib. The heart of the emulation is a compatibility C library, /usr/5lib/libc.a. This library attempts rather successfully to emulate the behavior of real UNIX System V C library routines, including system calls, as accurately as could be accomplished efficiently, even down to the errno codes. As far as a programmer operating in this environment is concerned, he is using UNIX System V (with bug fixes, modernized cxref, and "classes"). User utilities such as "ps" that didn't make much sense to adapt to the Berkeley system have been omitted from /usr/5bin, so the user gets the distributed 4.2BSD version of such things. The roughest spot is the use of Berkeley object module format, since the kernel doesn't know how to exec UNIX System V objects; this forced adoption of the Berkeley "as", "ld", and "ar" (complete with "ranlib", ugh) instead of UNIX System V Common Object File Format. This could perhaps be fixed by someone who wants to hack on the Bell "ld", but I didn't feel it was necessary for normal use. Terminal ioctl() is emulated remarkably well, considering how different the Bell and Berkeley terminal drivers are. I did not try to provide Bell-style IPC or FIFOs, since efficient emulation of these facilities would require kernel changes. The overriding rule when developing this package was to NOT CHANGE THE BERKELEY SYSTEM; apart from a couple of bug fixes involving SIGCHLD and a replacement Bourne shell (upward-compatible), the UNIX System V package installation consists merely of ADDING directories to the system. I also didn't provide X.25 or KMC support, which require kernel work, nor RJE, mail, or UUCP, which a Berkeley system will probably provide its own facilities for. It is easy enough to compile UNIX System V sources to provide anything I omitted that you need to have; the only real glitches may be embedded pathnames and accessing directories (for the latter, I have included Berkeley-style directory access routines in the C library). In general, it is not wise to attempt to mix 4.2BSD and UNIX System V modes. I did provide all the incompatible Berkeley system calls in the C library, using names beginning with an underscore (e.g., _gethostbyname()), just in case you need them; mostly these were intended for use in compatibility C library routines (for example, ioctl() calls on _ioctl()). Although I had to lengthen C variable names to support some of the Berkeley kernel calls, I did not extend the name length very far (limit 16 chars) and "lint" will definitely complain about long identifiers (as it SHOULD; they violate the C language standard). "cpp" has an option to permit redefining really long symbols if required in order to adapt code from a Berkeley system. You can get this package "free" by sending the following: xo Copy of the relevant pages of your UNIX System V license (either source or binary, although source is recommended) xo Statement of desired tape density (1600 bpi default) xo A reel of magtape (1200' is sufficient at 1600 bpi) xo Your return mailing address xo If you prefer to wait for the 4.2BSD version (we are running 4.1cBSD until our 4.2BSD tape arrives), you should so state; otherwise you get a copy of whatever I have when I write the tape to the following address: Douglas A. Gwyn U.S. Army Ballistic Research Lab. DRSMC-BLV-V Aberdeen P.G., MD 21005 (301)278-6647 gwyn@brl-vld.arpa or {decvax,esquire,unc}!brl-bmd!gwyn Effective use of this environment requires that you have UNIX System V user documentation; although /usr/5bin/man does know how to print the appropriate manual pages, users still need printed manuals. Of course I am not in a position to offer support, although I accept bug reports and gradually evolve the package, since we do use it ourselves.