This note describes the expected environment that this distribution expects to live in, and what must be done to a standard vanilla V6 Unix in order to build a network system. The code is distributed in unrooted form; that is, only partial pathnames are used. The set of directory names reflects an organization similar to a standard V6 system. The first-level directories are those that you would expect to find in either /usr/sys or /usr/source. (Since the source site for this stuff can only afford a single mounted filesystem for sources, we keep in all in /usr/sys. This causes some confusion for the files normally in /usr/source, but hang in there -- it all works out.) The directories in the distribution normally found in /usr/sys are h, conf, ken, dmr, ncpk, and ncpd. The directories normally found in /usr/source are ncpp, and s?. The sources in /usr/sys are those files sufficient to prepare a runnable kernel and NCP daemon. The sources in /usr/source are the network-related programs (server daemons, user programs, utilities, etc.) and those programs which are either different (modified) from the Bell distribution or not included in it in the first place. (The latter programs come from many sources; we only serve as a retransmission point.) To get going, there are a number of things that must be done. First, the vanilla C compiler doesn't have a large enough symbol table for some of the network modules, so it must be expanded. A new C supervisor is in s1/cc.c; this should be compiled and installed. It is upward compatible from the V6 distribution, and a number of the shell files expect it. ((Other C modules that were changed? Check with Glen.)) Also included as s1/sh.c is a modified version of the Yale shell. The major thing that has been done to it is that it now checks for new mail just prior to printing out the prompt. This is very useful in a network environment, where mail can come from the blue and need to be acted upon. Obviously, if the shell now checks for the mail, login needn't. The source for a much-modified login responder is located in s1/login.c. It does a number things that the original did not. As far as vanilla operation is concerned, you shouldn't be able to tell the difference. However, it gives a great deal more flexibility in terms of controlling the user's view of the system. The differences are the subject of another documentation file. ((Other things.)) Now you are ready to try to build system. There is a shell file named 'compile' that controlls the whole operation. It compiles a complete new system based upon the contents of a directory whose name you specify. The directory contains: . a file named 'configuration' that specifies which devices are to be included. . a file named 'conf.mod' that is used to tailor the configuration files that result from running 'configuration' into mkconf. . any *.h files that are specific to this configuration. Usually this means (at least) param.h. . any *.c files that are specific to this configuration. The 'configuration' file is passed to mkconf, which produces as output two files: c.c and l.s. The former is the initialization for the bdevsw and cdevsw tables, and hence control the meaning of the major device numbers. The distribution mkconf also includes initialization for nblkdev and nchrdev. The l.s file is an assembler file that contains the low core interrupt vectors and the interfaces to the machine-assist module (mch.c). The distribution mkconf plugs all the undefined locations with a transfer to a routine that displays a message and proceeds. It keeps the system from crashing. Since mkconf is somewhat inflexible about what it will generate where, you may want to edit c.c and l.s before they are actually compiled/assembled. So, after they are generated from the 'configuration' file, the editor is entered with 'conf.mod' as a script. Here you can make any changes to the files that you wish. (This file is actually optional; if it is not present, c.c and l.s are used as is.) Since the filename is NOT specified, you must use a "e c.c" to get c.c, make whatever changes you want, write it back out, use a "e l.s" to get l.s, etc. This is a very powerful feature, but you must really know what you are doing in order to make it work. Use it with care. The remainder of the files that are compiled and included in the system are subject to a search order. The theory is that there are really three levels of "interesting" sources. First, there may be sources that are special to one system. These may either be custom-tailored modules that provide some special function, or a pre-release of new system modules (this is how I test new modules before I let other people try them). Then there may be a set of sources that represent the current "working" system. Beyond that there is the baseline "backup" system that represents the solid, reilable system. The compile file reflects this ordering by searching a series of directories to find each module to be compiled. It first searches the directory that the compile is relative to, then a local subdirectory with the same name as the system directory, and finally the system directory (which, as you recall, is /usr/sys). Thus, if the compile is relative to the 'test' directory, and bio.c of the 'dmr' directory is to be compiled, it will first look for test/bio.c, then dmr/bio.c, and finally /usr/sys/dmr/bio.c to find the file to be compiled. The #included *.h files are subject to a similar search order. The compiler supports the search order directly via an option. In this case, the search order is 'test', 'h', '/usr/sys/h', and finally '/usr/include'. The last one is present since that's where V7 systems keep their #include files.