Commit | Line | Data |
---|---|---|
15637ed4 RG |
1 | This is the kernel source tree, where new versions of the operating system |
2 | can be made. | |
3 | ||
4 | Machine dependent sources are segregated into a directory | |
5 | heirarchy (i386/), within which hardware drivers are isolated in a per-bus | |
6 | directory (i386/isa), processor specific archetecture files may be found | |
7 | in a per-processor directory (i386/i386), and externally visiable machine | |
8 | dependant include files may be found also in a seperate directory | |
9 | (i386/include -- note: these are referred to explicitly via the "machine" | |
10 | include file symbolic link, or, implictly via the master include files in | |
11 | located in /usr/include -- thus <sys/types.h> will include | |
12 | i386/include/types.h, for example). System configuration files, are located | |
13 | in a configuration directory (i386/conf), from where the config program | |
14 | *must* be run as the first step in making a new system kernel. | |
15 | ||
16 | Generic machine-independant code is located in the various directories | |
17 | (kern, ufs, nfs, isofs, vm, net, netinet, stand, ddb, sys, conf). | |
18 | The central kernel is in the "kern" directory, and all of it's include files | |
19 | and shared definitions with other kernel subsystems are located in the | |
20 | "sys" include file directory. Filesystem dependant code (ufs, nfs, isofs) | |
21 | are located in their respective directories, and interface to the kernel | |
22 | via a virtual filesystem interface (vfs), definied within the kernel proper. | |
23 | The virtual memory subsystem is located in the "vm" directory. It's interface | |
24 | is subject to considerable revision. The optional in kernel debugger is | |
25 | present in two directories (ddb, i386/ddb), to use it you must compile the | |
26 | system with the "ddb" device, and load the symbol table with the "dbsym" | |
27 | command. Networking interface code is in the "net" directory, while "netinet" | |
28 | holds the INTERNET core protocol implementation. Shared standalone bootstrap code | |
29 | is in the "stand" directory. | |
30 | ||
31 | The directory "compile" holds all per-host compilation directories. In use, | |
32 | one goes to the i386/conf directory, runs the config program on a host | |
33 | description file (e.g. config SUMNER), which builds the "compile/SUMNER" | |
34 | directory and all files. Then, in the "compile/SUMNER" directory, the | |
35 | command "make depend" is used to build the dependency graph (.depend) | |
36 | for make. Next, the system is compiled from scratch by typing "make". | |
37 | The system may be tested by copying into a floppy that holds a minimal | |
38 | set of utilies (e.g. fixit floppy), and when satisfactory, can be copied | |
39 | into the root as /386bsd on the hard disk, and the system rebooted. | |
40 | ||
41 | To debug the system, one can use the "gdb" debugger to examine post-mortum | |
42 | dumps, or to modify kernel memory on a running system (e.g. setting | |
43 | debug flags in drivers). To read a postmortum (in /var/crash), type something | |
44 | like "gdb -k /var/crash/system.N /var/crash/ram.N", for the Nth dump you | |
45 | wish to examine. To look at a running system, "gdb -k /386bsd /dev/mem". | |
46 | For in-kernel debugging, one can compile in the "ddb" debugger and enter | |
47 | it by typing CTRL, ALT, and ESC simulatineously. Finally, printfs can be | |
48 | scattered in the kernel for debugging, just like user programs. | |
e4270b63 RG |
49 | |
50 | $Id$ |