Updated 1997/2/14 This directory contains prototypes of the files necessary to remaking the kernel. The kernel is not compiled or loaded in this directory, but in individual directories per machine. To set up a directory for a new machine, copy the file GENERIC to a file with the same name as the machine, and edit it to describe the desired kernel and the machine's hardware configuration. Then, run the script "./config", giving it the file name as an argument. Config will create a directory ../machinename and will copy or create the necessary files in it. When creating a GENERIC system remember to copy /sys/pdpdist/dtab to /etc/dtab before creating the dump(8) of the root filesystem. This is so 'autoconfig' will find the tape and disc devices when the GENERIC kernel is booted. You will probably need to change the overlay definitions in the Makefile, if you are going to run an overlaid kernel, but most of the work of configuring a system will be done. OVERLAY notes: Almost none of the CONF modules can be placed in overlays. In general assembly language modules (source files ending in .s) may not be placed in overlays because they do not observe the overlay calling sequence used by the .c modules. Other than that restriction modules may be placed in overlays in any order subject to the size constraints mentioned below. It is a good idea to attempt to group modules which call each other in the same overlay when possible, this saves overlay switching overhead. It is a very good idea to keep the frequently/constantly called modules (such as ufs_namei.o or tty.o) in the BASE segment. If the system has a large amount of memory and swapping does not occur often then the swap (vm_swap.o, etc) modules are good candidates for being placed in overlays. Maximum size of the BASE is 56kb, maximum size of each overlay segment is 8kb - the 'checksys' program will warn of segments (root/base, overlays and data) which are too large. There is a limit of 15 overlays at present, however there is a lower limit on the size of a kernel which may be loaded. /boot can not deal with kernels larger than about 192kb (sum of text and data) because that is where /boot relocates himself to while loading /unix. See the comments in /sys/pdpstand/M.s for more information and a workaround (which will not work with the 3Com ethernet board installed in the system). There is one possible problem that you need to be aware of. Running the shell script config generates the file localopts.h in the system include files directory, "../h". If you change your configuration, config will overwrite your old version of that file. Therefore, if you want to return to the old version of your system, you'll have to recover the file before you try and remake the old system. To make this easy, config saves a copy in the kernel directory. Almost no applications depend on localopts.h now, pstat.c and mkfs.c are the only ones which come to mind. 'pstat' and 'mkfs' need the EXTERNALITIMES define. ALL other options have either been deleted (obsolete) or made standard. The few remaining options have been moved into the kernel Makefile as "-Dxxx" flags to the compiler. If EXTERNALITIMES changes you will need to recompile anything which looks at the kernel's incore inode table. The directory VAX.compile contains a C preprocessor that defines "pdp11" and a C compiler that knows where to find said preprocessor. If you compile and install VAX.compile/cpp as VAX.compile/CPP and VAX.compile/cc.c as VAX.compile/CC, then do "./config VAX", you can compile the entire kernel on a larger machine; obviously, this is more of a test for syntax/load errors than anything else. If you're interested, it usually took me about 5 minutes to compile the entire networking kernel on a VAX 8600.