- Introduction
- Booting a System
- The OpenBoot Environment
- The OpenBoot Architecture
- The OpenBoot Interface
- Getting Help in OpenBoot
- PROM Device Tree (Full Device Pathnames)
- OpenBoot NVRAM
- OpenBoot Security
- OpenBoot Diagnostics
- OpenBoot PROM Versions
- Booting a System
- The Kernel
- The init Phase
- System Shutdown
- Summary
- Suggested Readings and Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
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, others—such as device drivers—are 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:
- The search path for default modules to be loaded at boot time as well as the search path for modules not to be loaded at boot time
- The modules to be forcibly loaded at boot time rather than at first access
- The root type and device
- The new values to override the default kernel parameter values
The following is an example of the default /etc/system file:
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
The /etc/system file contains commands that have this form:
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:
set nfs:nfs_nra=4
This parameter controls the number of read-ahead operations that are queued by the NFS version 4 client.
Commands that affect loadable modules have this form:
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.
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.