/joh'liks/ n.,adj. 386BSD
With the kernel running, we do a "high level bootstrap" to initialize the operating system, by executing certain programs located in the root filesystem.
|
Although many PCs frequently run UNIX with a sole user, /sbin/init can also prepare the system for multiuser or multitasking operation. In this case, init runs the command interpreter on a file of commands (/etc/rc) commonly referred to as a "shell script." This in turn calls other shell scripts for network, device, and server process invocation. Server processes, which provide for a variety of services available with UNIX systems are often referred to as "daemons," as they attempt to do work invisibly. This is a play on Maxwell's daemon, who would merrily put hot molecules in one box and cool molecules in another box, thus (?) violating the Second Law of Thermodynamics. (The proof fails when the daemon acquires so much energy in rapid collisions from highly vibrating molecules that it must radiate the energy as heat, thus perturbing the system. See Feynman's Lectures on Physics, Volume 1, for more information. You just can't get something for nothing, can you?) Among other things, the system may now perform housekeeping functions: fixing any broken filesystems it can, erasing temporary files and other garbage, adding filesystems (both on the computer and over the network), and connecting the system into the world. Traditionally, all these commands provide little output as they are launched --which can occasionally confuse more than reassure. One popular computer author, unfamiliar with UNIX, complained of feeling quite uncomfortable when a UNIX workstation flashed him the message, "starting standard daemons." Perhaps he thought he needed the help of a system exorcist! In multiuser operation, the system depends on all the functionality that has been configured, including indications of service availability through the appearance of a login prompt. We find it amusing when our 386 PC laptop prompts us for a login account name and password, as if we are competing with hundreds of users for access to the machine! On the other hand, our little 386 laptop, running 386BSD, has about as much disk space and memory and is three times the speed of the PDP 11/70 that the University of California used to run 50 to 70 students at a clip. UNIX regards little PCs and systems with hundreds of terminals in the same way -- a login prompt per customer. Configuration: /dev and /etc Hardware devices on UNIX are accessed through special filenames in /dev. For our filesystem to work correctly, we must have the appropriate device files already made. Otherwise, the utility programs will not be able to access the devices, even if the operating system has drivers that work with the underlying hardware. These files are special because they are made with a special program (/sbin/mknod) which creates an association between the file and a software driver in the kernel. A shorthand script program (/dev/MAKE-DEV) provides a way to make these files symbolically. With 386BSD, we must make the console (/dev/console) and the root filesystem's device (/dev/wdOa) before we run; it's wise to make other special files at this time, too. Besides configuring device filenames, we need to specify device configuration for disk drives (/etc/fstab), terminal lines (/etc/ttys), and printers (/etc/printcap) to describe device characteristics. One criticism of all UNIX systems has been the need to wade through a plethora of ad hoc configuration files for device and program use. Most of the system configuration files in this project, however, can be found within the /etc directory.
|
|