The Kernel

After the boot command initiates the kernel, the kernel begins several phases of the startup process. The first task is for OpenBoot to load the two-part kernel. The secondary startup program, ufsboot, which is described in the preceding section, loads the operating system kernel. The core of the kernel is two pieces of static code called genunix and unix. genunix is the platform-independent generic kernel file, and unix is the platform-specific kernel file. The platform-specific kernel used by ufsboot for systems running in 64-bit mode is named /platform/'uname -m'/kernel/sparcv9/unix. Solaris 10 only runs on 64-bit systems; however, early versions of Solaris gave you the option of running in 32-bit or 64-bit mode. On previous versions of Solaris, the 32-bit platform-specific kernel was named /platform/'uname -m'/kernel/unix. Now, in Solaris 10, /platform/'uname -m'/kernel/unix is merely a link to the 64-bit kernel located in the sparcv9 directory. When ufsboot loads genunix and unix into memory, they are combined to form the running kernel.

The kernel initializes itself and begins loading modules, using ufsboot to read the files. After the kernel has loaded enough modules to mount the root file system, it unmaps the ufsboot program and continues, using its own resources. The kernel creates a user process and starts the /sbin/init daemon, which starts other processes by reading the /etc/inittab file. (The /sbin/init process is described in the "System Run States" section, later in this chapter.)

The kernel is dynamically configured in Solaris 10. The kernel consists of a small static core and many dynamically loadable kernel modules. Many kernel modules are loaded automatically at boot time, but for efficiency, otherssuch as device driversare loaded from the disk as needed by the kernel.

A kernel module is a software component that is used to perform a specific task on the system. An example of a loadable kernel module is a device driver that is loaded when the device is accessed. Drivers, file systems, STREAMS modules, and other modules are loaded automatically as they are needed, either at startup or at runtime. This is referred to as autoconfiguration, and the kernel is referred to as a dynamic kernel. After these modules are no longer in use, they can be unloaded. Modules are kept in memory until that memory is needed. This makes more efficient use of memory and allows for simpler modification and tuning.

The modinfo command provides information about the modules that are currently loaded on a system. The modules that make up the kernel typically reside in the directories /kernel and /usr/kernel. Platform-dependent modules reside in the /platform/'uname -m'/kernel and /platform/'uname -i'/kernel directories .

When the kernel is loading, it reads the /etc/system file where system configuration information is stored. This file modifies the kernel's parameters and treatment of loadable modules. It specifically controls the following:

login: login: root
Password:
Last login: Tue Jul 26 22:23:37 on console
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
# cd /sbi
/sbi: does not exist
# cd /sbin
# ls init
init
# ls -l init
-r-xr-xr-x   1 root     sys        48984 Jan 22  2005 init
# cd /etc
# ls init
init
# ls -l init
lrwxrwxrwx   1 root     root          12 Feb 25 14:26 init -> ../sbin/init
# more /etc/system
*ident  "@(#)system     1.18    97/06/27 SMI" /* SVR4 1.5 */
*
* SYSTEM SPECIFICATION FILE
*

* moddir:
*
*       Set the search path for modules.  This has a format similar to the
*       csh path variable. If the module isn't found in the first directory
*       it tries the second and so on. The default is /kernel /usr/kernel
*
*       Example:
*               moddir: /kernel /usr/kernel /other/modules



* root device and root filesystem configuration:
*
*       The following may be used to override the defaults provided by
*       the boot program:
*
*       rootfs:         Set the filesystem type of the root.
*
*       rootdev:        Set the root device. This should be a fully
*                       expanded physical pathname. The default is the
*                       physical pathname of the device where the boot
*                       program resides. The physical pathname is
*                       highly platform and configuration dependent.
*
*       Example:
*               rootfs:ufs
*               rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a
*
*       (Swap device configuration should be specified in /etc/vfstab.)



* exclude:
*
*       Modules appearing in the moddir path which are NOT to be loaded,
*       even if referenced. Note that 'exclude' accepts either a module name,
*       or a filename which includes the directory.
*
*       Examples:
*               exclude: win
*               exclude: sys/shmsys



* forceload:
*
*       Cause these modules to be loaded at boot time, (just before mounting
*       the root filesystem) rather than at first reference. Note that
*       forceload expects a filename which includes the directory. Also
*       note that loading a module does not necessarily imply that it will
*       be installed.
*
*       Example:
*               forceload: drv/foo



* set:
*
*       Set an integer variable in the kernel or a module to a new value.
*       This facility should be used with caution.  See system(4).
*
*       Examples:
*
*       To set variables in 'unix':
*
*               set nautopush=32
*               set maxusers=40
*
*       To set a variable named 'debug' in the module named 'test_module'
*
*               set test_module:debug = 0x13

Caution

Modifying the /etc/system File A system administrator will modify the /etc/system file to modify the kernel's behavior. By default, the contents of the /etc/system file are completely commented out and the kernel is using all default values. A default kernel is adequate for average system use and you should not modify the /etc/system file unless you are certain of the results. A good practice is to always make a backup copy of any system file you modify, in case the original needs to be restored. Incorrect entries could prevent your system from booting. If a boot process fails because of an unusable /etc/system file, you should boot the system by using the interactive option boot -a. When you are asked to enter the name of the system file, you should enter the name of the backup system filename or /dev/null, to use default parameters.

set <parameter>=<value>

For example, the setting for the kernel parameter nfs:nfs4_nra is set in the /etc/system file with the following line:

This parameter controls the number of read-ahead operations that are queued by the NFS version 4 client.

set <module>:<variable>=<value>

For the most part, the Solaris OE is self-adjusting to system load and demands minimal tuning. In some cases, however, tuning is necessary.

If you need to change a tunable parameter in the /etc/system file, you can use the sysdef command or the mdb command to verify the change. sysdef lists all hardware devices, system devices, loadable modules, and the values of selected kernel-tunable parameters. The following is the output that is produced from the sysdef command:

* Hostid
*
  80a26382
*
* sun4u Configuration
*
*
* Devices
*
scsi_vhci, instance #0
packages (driver not attached)
        terminal-emulator (driver not attached)
        deblocker (driver not attached)
        obp-tftp (driver not attached)
        disk-label (driver not attached)
        SUNW,builtin-drivers (driver not attached)
        sun-keyboard (driver not attached)
        ufs-file-system (driver not attached)
chosen (driver not attached)
openprom (driver not attached)
        client-services (driver not attached)
options, instance #0
aliases (driver not attached)
memory (driver not attached)
virtual-memory (driver not attached)
pci, instance #0
        pci, instance #0
                ebus, instance #0
                        auxio (driver not attached)
                        power, instance #0
                        SUNW,pll (driver not attached)
                        se, instance #0
                        su, instance #0
                        su, instance #1
                        ecpp (driver not attached)
                        fdthree, instance #0
                        eeprom (driver not attached)
                        flashprom (driver not attached)
                        SUNW,CS4231, instance #0 (driver not attached)
                network, instance #0
                SUNW,m64B, instance #0
                ide, instance #0
                        disk (driver not attached)
                        cdrom (driver not attached)
                        sd, instance #1
                        dad, instance #1
        pci, instance #1
Output has been truncated . . . . . . .

* System Configuration
*
  swap files
swapfile            dev  swaplo blocks   free
/dev/dsk/c0t0d0s3  136,11     16 1052624 1052624
*
* Tunable Parameters
*
 2498560        maximum memory allowed in buffer cache (bufhwm)
    1914        maximum number of processes (v.v_proc)
      99        maximum global priority in sys class (MAXCLSYSPRI)
    1909        maximum processes per user id (v.v_maxup)
      30        auto update time limit in seconds (NAUTOUP)
      25        page stealing low water mark (GPGSLO)
       1        fsflush run rate (FSFLUSHR)
      25        minimum resident memory for avoiding deadlock (MINARMEM)
      25        minimum swapable memory for avoiding deadlock (MINASMEM)
*
* Utsname Tunables
*

    5.10  release (REL)
  ultra5  node name (NODE)
   SunOS  system name (SYS)
 Generic  version (VER)
*
* Process Resource Limit Tunables (Current:Maximum)
*
0x0000000000000100:0x0000000000010000   file descriptors
*
* Streams Tunables
*

     9  maximum number of pushes allowed (NSTRPUSH)
 65536  maximum stream message size (STRMSGSZ)
  1024  max size of ctl part of message (STRCTLSZ)
*
* IPC Messages module is not loaded
* IPC Semaphores module is not loaded
* IPC Shared Memory module is not loaded
* Time Sharing Scheduler Tunables
*
60      maximum time sharing user priority (TSMAXUPRI)
SYS     system class name (SYS_NAME)

The mdb command is used to view or modify a running kernel and must be used with extreme care. The use of mdb is beyond the scope of this book; however, more information can be obtained from The Solaris Modular Debugger Guide available at http://docs.sun.com.

Note

Kernel Tunable Parameters in Solaris 10 You'll find in Solaris 10 that many tunable parameters that were previously set in /etc/system have been removed. For example, IPC facilities were previously controlled by kernel tunables, where you had to modify the /etc/system file and reboot the system to change the default values for these facilities. Because the IPC facilities are now controlled by resource controls, their configuration can be modified while the system is running. Many applications that previously required system tuning to function might now run without tuning because of increased defaults and the automatic allocation of resources.

Configuring the kernel and tunable parameters is a complex topic to describe in a few sections of a chapter. This introduction to the concept provides enough information for the average system administrator and describes the topics you'll need to know for the exam. If you are interested in learning more about the kernel and tunable parameters, refer to the additional sources of information described at the end of this chapter .