Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Kernel
This section describes the kernel and includes reference tables for kernel-related parallels between Linux and Solaris and file system types. This section contains the following topics:
"Versions"
"Configuring and Compiling"
"Modules and Drivers"
"File Systems"
"Swap"
Versions
Kernel versions in Linux follow a scheme of x.y.z, where x is the major release number, y is the minor release number, and z is the feature or bug fix release level. The major release level is currently 2. An even number for y represents stable kernel releases where only bug fixes are applied as updates. An odd number for y represents a development release, where new features can be added as updates. For example 2.0, 2.2, and 2.4 are stable production kernels, whereas 2.1, 2.3, and 2.5 are development kernels. When a development kernel reaches a critical mass in new features, a new production version is released.
The z number is analogous to a Solaris kernel update patch (KUP) revision number. It represents the feature release level for development kernels, and the bug fix level for stable kernels.
The standard way to update your kernel in Redhat Linux is to use rpm(8) to install a new binary release of it. If you have a custom kernel, you can update it by applying a source-code patch, in which case you need to recompile the kernel.
The kernel source and patches are available from http://www.kernel.org.
Configuring and Compiling
With Solaris 9 OE, just plugging in a new hardware component may be all that is required to install it. More commonly, a pkgadd and reboot is done. It all depends on whether the driver is native in Solaris, and whether the hardware can be physically installed without bringing the system down.
The stock kernel installed by default in Redhat Linux can recognize and load drivers for a wide array of hardware, so it may be sufficient for most purposes. If either your hardware requirements go beyond what is in the stock kernel, or you want to remove unneeded drivers built in to the kernel, a kernel rebuild is required. The details of the process are beyond the scope of this article, but the general steps are as follows:
Install the kernel source tree in /usr/src.
Build the configuration in /usr/src/linux via make config, make menuconfig, or make xconfig.
Build the kernel dependencies via make dep.
Build the kernel itself via make.
Build all components you designated to run as modules in step 2 via make modules.
Make a backup copy of your current kernel, and put a corresponding entry for it in /etc/lilo.conf or /boot/grub/grub.conf.
Install the kernel via make install (installs the kernel into /boot and runs LILO).
Install your modules via make install_modules (installs modules into /lib/modules/'uname -r').
Reboot using the new kernel.
The configuration phase of building a new kernel (step 2 in the previous list) creates a file called .config in the main kernel source directory. It's a good practice to save a copy of this file elsewhere after you get a good working configuration. If you find yourself upgrading to a new kernel with a new source tree, you can usually just copy this file into the new kernel directory.
More information on building custom kernels is on the Web at: http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Kernel-HOWTO.html.
Modules and Drivers
The Solaris kernel is entirely modular. The kernel itself performs a core functionality with anything beyond that requiring it to dynamically load a chunk of code to perform the task. These chunks of code are in the form of dynamically linked loadable modules. The Linux kernel can be modular in this fashion, if it is built that way from source. Most drivers have the option of being modules, or being compiled into the kernel itself. However, if a driver is needed as a component required to access the root file system, then compiling it as a module requires you to use an initial RAM disk (initrd) as part of the boot process. The initrd allows you to have a root file system accessible, complete with /lib/modules directory, before the real root file system is mounted. Solaris avoids this situation by using a file-system-aware boot loader (ufsboot) that is capable of finding the required modules within a UNIX file system (UFS) before the root file system is actually mounted.
By default, the Solaris kernel searches for modules from the following four directories in this order:
/platform/'uname -i'/kernel
/platform/'uname -m'/kernel
/kernel
/usr/kernel
If you add a new module, you can load it into the kernel immediately by installing it into one of these directories, running add_drv to assign it a major number, and running devfsadm to create the device nodes needed to access the new hardware or protocol.
Linux modules are located in /lib/modules/'uname -r'. To add a module dynamically into a running kernel, compile it and install it into /lib/modules/'uname -r'. Then use the depmod -a command to map out any dependencies for the module. If depmod comes up with unresolved dependencies, it's possible that you need to recompile the kernel to resolve the dependencies.
After running depmod successfully, use modprobe or insmod to load the module. The modprobe command checks the dependencies mapped out by depmod and automatically loads any modules deemed as dependencies. For example, if you have sunrpc and nfsd compiled as kernel modules and modprobe loads the nfsd module, the sunrpc module is automatically loaded first, because the networked file system (NFS) needs remote procedure call (RPC) to operate. The insmod command is the same as modprobe, except that it does not check for dependencies. If there is a dependency that is not satisfied, insmod fails and displays an error message about unresolved dependencies.
The module interface in Linux has a configuration file called /etc/modules.conf. In this file, you can create module aliases, set driver options, and execute commands to run before or after a module is loaded.
Both the modprobe and depmod commands reference this file. Driver parameters are set via an options statement for the module in the /etc/modules.conf file, similar to the way you set them in /etc/system or kernel/drv/<module>.conf in Solaris. Possible driver parameters for a module can be listed via modinfo -p <modulename>. If the module supports it, you can also set parameters via the proc file system interface, or the sysctl command, which uses the proc file system interface. Retrieving and setting module parameters using the proc interface is generally accomplished by manipulating the contents of files located in the /proc directory. TABLE 3 shows the module-related parallels between Solaris and Linux.
TABLE 3 Module-Related Parallels Between Solaris and Linux
|
Solaris |
Linux |
Purpose |
|
modinfo |
lsmod |
List loaded modules |
|
modload |
modprobe/insmod |
Load a module |
|
modunload |
rmmod |
Unload a module |
|
add_drv |
depmod* |
Install a new module |
|
ndd -get |
modinfo -p or /proc file system interface |
Get module parameters |
|
/etc/system or kernel/drv/<module>.conf |
options line for module in /etc/modules.conf or modprobe <module> symbol=value or insmod <module> symbol=value |
Set module parameters at module load time |
|
ndd -set |
sysctl / proc file system interface |
Set module parameters on the fly |
|
/etc/driver_aliases |
alias option in /etc/modules.conf |
Module aliases |
|
/etc/name_to_major |
Fixed list if not using devfs. See "Device Nodes" on page 8. |
Module major numbers |
*Not an exact comparison. Because major and minor numbers are predefined in Linux, the functionality that Solaris gets from add_drv is not needed in Linux. Running depmod is just the final step in adding a module to a system.
A STREAMS driver implementation called LiS is available in Linux. The implementation is built outside of the kernel source tree and runs as a loadable module. You can download LiS from http://www.gcom.com/.
File Systems
One of the advantages to an open-source operating environment like Linux is that when you want to get something to work, somebody has probably already written a driver for it. This includes file system drivers. For example, in Redhat 8.0, there are no less than 31 file system types supported. However, some of these file system types were ported for read-only access, with an experimental interface for write support. TABLE 4 lists some file system types available in Solaris and their counterparts in Linux.
TABLE 4 File System Types in Solaris and Linux
|
Solaris |
Linux |
|
autofs |
autofs |
|
nfs |
nfs |
|
udfs |
udfs |
|
hsfs |
iso9660 |
|
procfs |
proc |
|
tmpfs |
tmpfs |
|
ufs |
ufs |
|
pcfs |
msdos/vfat |
|
ext2fs* |
ext2 |
* A driver has been written at Sun, but is unsupported.
An installation of Linux initially boots to an environment that has different file system types mounted. TABLE 5 is a list of file systems you might find after installing.
TABLE 5 Linux File System Types
|
Mounted On |
File System Type |
Purpose |
|
/ |
ext2/ext3 |
Standard Linux file system. |
|
/boot |
ext2/ext3 |
Standard Linux file system. |
|
/proc |
proc |
Contains process information mapped out so that it can be accessed within a virtual file system framework. In Linux, /proc also provides an access mechanism to data contained within the kernel and kernel modules. This access mechanism is analogous to the ndd command in Solaris. |
|
/dev/pts |
devpts |
Interface used to allocate pseudo tty devices. |
|
/dev/shm |
tmpfs |
tmpfs interface for shared memory. A tmpfs in Linux works the same as it does in Solaris. The difference here is that the tmpfs is mounted on /dev/shm. This requirement is for glibc 2.2 and newer. |
The complete list of Linux file system support taken from the mount(8) manual page is as follows: adfs, affs, autofs, coda, coherent, cramfs, devpts, efs, ext, ext2, ext3, hfs, hpfs, iso9660, jfs, minix, msdos, ncpfs, nfs, ntfs, proc, qnx4, reiserfs, romfs, smbfs, sysv, tmpfs, udf, ufs, umsdos, vfat, xenix, xfs, xiafs.
Swap
Swap space can be allocated as a file or a partition in Linux. Before swap space is used, it must be formatted via mkswap.
CAUTION
Be aware that Solaris x86 and Linux swap have the same partition types, and running mkswap on a Solaris x86 partition destroys it. See "Partition Tables" on page 18.
As in Solaris, any swap partitions defined in the file system table (/etc/fstab in Linux) are activated at boot time. In Linux, /sbin/swapon -a is the mechanism for doing this. You can remove a swap file or partition from use by the kernel with swapoff. Like Solaris, Linux users have all kinds of theories as to what size swap should be for a system, and this subject is not within the scope of this article. Like Solaris, Linux does not require the use of swap.