System Configuration

Changes related to system configuration include the dynamically loaded kernel and kernel layout, the config and boot commands, and the /etc/system file.

Dynamically Loaded Kernel

Unlike previous SunOS releases, the kernel is now dynamically configured. The kernel now consists of a small static core and many dynamically loadable kernel modules. Drivers, file systems, STREAMS modules, and other modules are loaded automatically as needed, either at boot time or at runtime. When

these modules are no longer in use, they may be unloaded. Modules are kept in memory until that memory is needed. modinfo(1M) provides information about the modules currently loaded on a system.

The modload(1M) and modunload(1M) commands are still available in this release, but they perform differently. These commands have more limited usage in this release, and are no longer sufficient to correctly install a loadable driver onto the system. modunload is similar to the SunOS release 4.x command, but it includes the capability to unload all unloadable (and not busy) modules. Use modunload as follows.

# modunload -i 0

Kernel Layout

The contents of the kernel, which were formerly in a single file, /vmunix, are now contained in modules in a directory hierarchy. By default, the directory hierarchy is /kernel and /usr/kernel.

The directory search path for modules can be set by the moddir variable in the /etc/system file. See the system(4) man page in man Pages(1M): System Administration Commands. Typically, /kernel/unix is the first portion of the kernel to be loaded. See the kernel(1M) man page in man Pages(1M): System Administration Commands.

The /kernel/drv directory is used for bootable devices and code that is specific to the sytem on which it runs. The /usr/kernel/drv directory is used for all other drivers.

config Command

In SunOS release 4.x, the config command was used to generate system configuration files that allowed /vmunix to be relinked from object files. The need for this command has been removed by the following Solaris 2.4 features:

• Loadable modules
• The /etc/system file (see the system(4) man page)
• Device tree information from the OpenBoot PROM (OBP)
• The driver.conf files in /kernel/drv and /usr/kernel/drv

/etc/system File

System configuration information is now set in the /etc/system file. This file also modifies the kernel's treatment of loadable modules. The file contains commands of the form:

set parameter=value

For example, in SunOS release 4.x, MAXUSERS was set using config(8). In the Solaris 2.4 operating environment, it is set in the /etc/system file with the following line.

set maxusers = number

Commands that affect loadable modules are of the form:

set module:variable=value

Changes made to the /etc/system file take affect when you reboot your system (see the system(4) man pages).

boot Command

In this release, the following boot programs are available:

• ufsboot - To boot from a disk
• inetboot - To boot from across the network
• hsfsboot - To boot from a CD-ROM

When booting from a disk, the PROM assumes that the primary boot block resides in blocks 1 - 15 of the local disk. Use installboot(1M) to create the boot block:

# installboot /usr/lib/fs/ufs/bootblk /dev/rdsk/c0t3d0s0

The system firmware loads the primary bootstrap (the boot block) program into memory and runs it. The boot block is a UFS file system reader. It loads the secondary boot program (/ufsboot) into memory.

/ufsboot loads /kernel/unix, then /kernel/unix uses ufsboot to load modules from the /kernel directory hierarchy until it is able to mount the root file system.

During these operations, the boot block and /ufsboot use the drivers provided by the firmware; neither ufsboot nor the boot block contains any driver code. In theory, the /ufsboot code would not have to change to incorporate a new SBus card with a new disk type since /ufsboot uses the SBus card PROM driver.

When booting over the network, the boot program performs as it did for a diskless boot in SunOS release 4.x. However, the boot program is now called inetboot and the client vfstab file entries are different. See File System Administration for information on diskless booting.

Summary of Boot Differences

Table 18-1 summarizes the differences in the boot sequence between SunOS release 4.x and the Solaris 2.4 operating environment.

Table 18-1

SunOS release 4.x	Solaris 2.4	Description
boot block	bootblk	Loads ufsboot from disk
boot program	ufsboot	Loads unix from disk
vmunix	unix	Bootable kernel image
boot.sun4c.sunos.4 .1.1	inetboot	Mounts and copies unix from network
rc.boot, rc.single	/etc/rcS	Mounts /usr and checks file systems
rc.local	/etc/rc2, /etc/rc3, /etc/rc2.d, /etc/rc3.d	System configutration scripts
config	modload, /etc/system, add_drv, rem_drv	Customizes system kernel, loads, adds, and removes modules as needed
prom monitor, single user, multiuser	run states 0 - 6, and S	System run levels

Device Configuration: The Reconfiguration Boot

A reconfiguration boot tells the system to probe for all connected devices and build the names for them in /devices and /dev. A reconfiguration boot, performed when adding new hardware to the system is triggered by booting with the -r option, which follows.

ok boot -r

Or, on a Sun-4 system, using the following.

>b -r

If another device of an existing type (with the driver already installed) is added, and you forget to do a reconfiguration boot, you can use the following commands to tell the system to recognize the new device.

# touch /reconfigure # /etc/init.d/drvconfig # /etc/init.d/devlinks

Device Naming From a Developer's Perspective

This section expands on the discussion in "Device Naming Conventions" on page 65, focusing on aspects of device naming that concern system and kernel developers.

/devices

The /devices tree represents the tree of devices recognized by the kernel. This tree is configured by the drvconfig(1M) program. drvconfig is normally run only when the system is booted with the -r flag. See "Device Configuration: The Reconfiguration Boot" on page 191. drvconfig configures /devices with information about devices (with drivers) that are connected and turned on at startup time.

Entries are exported by device drivers calling ddi_create_minor_node(9F) when they have determined that a device exists.

Use the add_drv(1M) command to add a device to the system. If the driver was successfully added, add_drv will also run drvconfig.

/dev

In this release, /dev is managed by utility programs that create symbolic links to the real entries in /devices. The programs are:

• disks(1M)
• tapes(1M)
• ports(1M)
• devlinks(1M)

You can run a script to create the appropriate links from /dev to /devices. The /dev names have the advantage of being simpler and more familiar, while the /devices names are exact names for the hardware.

Device Driver Naming

Each device in the system is driven by a device driver. Device drivers manage many instances of a device. Devices are named in several ways:

• Physical names
• Logical names
• Instance names

Physical Names

Physical names are stored in /devices. They describe the hardware, and vary with the platform and configuration. For example:

/devices/vme/xdc@6d,ee80/xd@0,0:g

Physical names can be used to identify which piece of hardware is in use. For example:

xdc@6d,ee80

refers to the disk controller at address 0xee80 in VME A16, D32 space. See vme(4), driver.conf(4), xy(7), and xd(7) in man Pages(1M): System Administration Commands.

Logical Names

Logical names are stored in /dev. They attempt to abstract most of the nature of physical device names that are specific to the platform. Logical names might be appropriate for an xd device, such as:

/dev/dsk/c2d0s6 (controller 2, slave 0, slice 6 (partition "g"))

or an sd device, such as:

/dev/dsk/c0t3d0s0 (controller 0, target 3, lun 0, slice 0 (partition "a"))

The logical name conveys nothing definite about the type of controller. That is, it does not differentiate between SCSI and IPI; they are both just disks.

Disk Names

Disk names use the SVR4 convention of slice numbers 0-7 instead of the letters a-h used in SunOS release 4.x.

Disk names also use the SVR4 convention of /dev/dsk/* for block disk devices and /dev/rdsk/* for raw disks. For more information, see Peripherals Administration.

Instance Names

Instance names refer to the nth device in the system, for example, sd20.

Instance names are occasionally reported in driver error messages. You can determine the binding of an instance name to a physical name by looking at dmesg(1M) output, as in the following.

sd9 at esp2: target 1 lun 1 sd9 is /sbus@1,f8000000/esp@0,800000/sd@1,0 <SUN0424 cyl 1151 alt 2 hd 9 sec 80>

Once the instance name has been assigned to a device, it remains bound to that device.

Instance numbers are encoded in a device's minor number. To keep instance numbers persistent across reboots, the system records them in the /etc/path_to_inst file. This file is read only at boot time, and is currently updated by the add_drv(1M) and drvconfig(1M) commands. See the path_to_inst(4) man page for more information.