UNIX System Administration Handbook - Evi Nemeth [143]
The modinfo command reports information about dynamically loaded modules. Solaris dynamically loads device drivers, STREAMS modules, and filesystem drivers, among other things. Don’t be surprised if modinfo’s output contains upwards of fifty entries. See page 253 for more information about modinfo.
12.4 BUILDING AN HP-UX KERNEL
HP-UX takes the older approach of building all of its drivers into one monolithic kernel. It also has a complex and confusing configuration file. However, HP-UX’s SAM administration tool provides a way to bypass all the nasty configuration files.
You should definitely use SAM the first few times you build an HP-UX kernel. The interface is straightforward: just click and build. One major drawback of building your kernel this way is that when you click “Process new kernel,” you must be prepared to reboot with the new kernel right then and there.
In this section we discuss building an HP-UX kernel by hand, since this procedure is generally undocumented by HP and is less obvious than using SAM. Building a kernel by hand gives you more control. You can configure the kernel, build it, and wait until the time is right to boot it. Also, you don’t need to have an X display or waste time clicking and dragging when the alternative is to type a couple commands.
The HP-UX kernel is configured in the file /stand/system. You should copy this file to a different name; we’ll use system.example. The system file is normally generated by SAM, so it is cryptic and uncommented. The only way to find out what all the bizarre commands and variables mean is to use SAM. Fortunately, you can load SAM and print out a copy of the configuration parameters screen. This procedure gives you a reference list of the names of configurable variables, a one-sentence description of their meanings, and their default values. We suggest keeping a copy around for reference.
Our system.example file is just a list of drivers, subsystems, and variables to be built into the kernel. In the file, devices are generally listed first, followed by subsystems. Variables and their values are listed last.
GSCtoPCI
asio0
c730
sdisk
sctl
cdfs
nfs_core
...
STRMSGSZ 65535
dump lvol
nstrpty 60
As you can see, deciphering this list can be difficult without the decoding guide from SAM. If a variable is set to the default value, it is left out of the configuration file. Table 12.4 lists some of the more frequently used variables and their default values.
Table 12.4 Useful variables from the HP-UX system file
Once you have built the system.example file, all that remains is to build the kernel with mk_kernel. By default, mk_kernel builds the kernel (using /stand/system) and puts it in /stand/vmunix.test. Use the -s flag to point mk_kernel at a different configuration file, and the -o flag to request a different target kernel name. For our example kernel, we’d use the following command:
# mk_kernel -s /stand/system.example -o /stand/vmunix.example
At this point, you can reboot any time you wish. If you want the new kernel to be booted automatically, copy your old /stand/vmunix somewhere else and put the new kernel in its place.
12.5 CONFIGURING A LINUX KERNEL
Linux kernel configuration has come a long way, but it still feels very primitive compared to most other systems. The process revolves around the /usr/src/linux/.config file. All of the kernel configuration information is specified in this file, but its format is pretty cryptic. To save folks from having to mess with the .config file, Linux has several make targets that let you configure the kernel with different interfaces.
If you are running X Windows, the prettiest configuration interface is provided by make xconfig. This command brings up a graphical configuration screen from which you can pick the devices you want added to your kernel (or compiled as a loadable module).
If you are not running X, you can use a curses-based1 alternative invoked with make menuconfig. Finally, there is the older style make config, which prompts you to respond