Chapter 18 System and Device Configuration

The operating system kernel and its interfaces have changed significantly. Binary compatibility is not provided for SunOS release 4 device drivers. This chapter discusses changes in the Solaris 7 operating environment that affect kernel and system developers.

• "System Configuration"

• "Reconfiguration Boot"

• "Device Naming From a Developer's Perspective"

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. They have more limited usage and are no longer sufficient to correctly install a loadable driver onto the system. modunload now 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/platform/'uname -i'/kernel, /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). Typically, /platform/'uname -i'/kernel/unix is the first portion of the kernel to be loaded (see the kernel(1M) man page).

config Command

In the SunOS release 4 software, the config command was used to generate system configuration files that enabled /vmunix to be relinked from object files. The need for this command has been removed by the following Solaris 7 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 the SunOS release 4 software, MAXUSERS was set using config(8). In the Solaris 7 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 only take effect 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 or a CD

• inetboot - To boot from across the network

  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/platform/'uname -i'/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 (/platform/'uname -i'/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. The ufsboot code does 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 the SunOS release 4 software. However, the boot program is now called inetboot and the client vfstab file entries are different. See System Administration Guide, Volume I for information on diskless booting.

Summary of Boot Differences

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

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.

ok> boot -r

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

# touch /reconfigure
# _INIT_RECONFIG=YES /etc/init.d/drvconfig
# _INIT_RECONFIG=YES /etc/init.d/devlinks

Device Naming From a Developer's Perspective

This section expands on the discussion in "Device Naming Conventions", 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 "Reconfiguration Boot"). drvconfig configures /devices with information about devices (with drivers) that are connected and ready at boot 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 unique 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 the vme(4) and driver.conf(4) man pages.

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 (4.x partition "g"))

or an sd device, such as:

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

The logical name conveys nothing about the type of controller. 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 the SunOS release 4 software.

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

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 example.

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 consistent 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.