Linux Command Line Parameters
Consider the following situations:
Scenario 1: You are installing Linux from CDROM, but the kernel isn't using the correct I/O address for your CD-ROM drive. You can correct this by recompiling the kernel, but to build the kernel you first need to install Linux from CD-ROM...
Scenario 2: You made a change to the system startup script rc.local and now your system hangs while booting. How can you fix the error without reinstalling Linux?
Scenario 3: You'd like to experiment with the various VGA console video modes available without having to recompile the kernel each time.
Scenario 4: You've just written a large application that runs well on your system. How well would it run on a friend's machine that has only 4MB of RAM and no floating point coprocessor?
One solution to each of these problems is provided by Linux and its ability to pass command line parameters to the kernel. Unfortunately, these options are not well documented, (some of the HOWTOs mention certain options in passing, e.g., the SCSI HOWTO mentions some SCSI related options) and a number of them have been added relatively recently. We'll explore them in this article.
In order to understand how command line parameters fit into the scheme of things, let's briefly look at what happens when Linux boots.
For those who aren't afraid to look at kernel source code, I'll mention some of the relevant files. The filenames given are relative to wherever you have installed the kernel source, usually /usr/src/linux. Therefore, a reference to the file boot/bootsect.S should be found in /usr/src/linux/boot/bootsect.S. This information is valid for Linux kernel version 1.2.
Starting from power on, the PC ROM BIOS routines load boot code from floppy or hard disk. If booting from hard disk, this is usually the boot loader installed by LILO. If booting fJ5m floppy, it is the code in the file boot/bootsect.S. This in turn loads the code found in boot/setup.S and runs it. This module reads some information from the BIOS (the VGA mode, amount of memory, etc.) and makes note of it for later use. It will be needed later as the BIOS routines will not (normally) be used once the kernel starts up.
The setup code next switches to protected (32-bit) mode, then loads and runs the code found in boot/head.S. (Actually, for compressed kernels, which is always the case in recent kernels, the kernel proper is first uncompressed using the code found in zBoot/head.S). This sets up more of the 32-bit environment, gets the command-line parameters (usually from LILO), and passes them to the routine start_kernel.
Up to now everything was written in assembly language. At this point we now switch to the function start_kernel, written in C, found in the file init/main.c. This is the code that does most of the option parsing, saving information on a number of kernel-specific parameters in global variables so that they can be used by the kernel when needed.
Any other parameters given as “name=value” pairs are passed as arguments and environment variables to the next process.
This first kernel process now sets some things up for multitasking, and makes the first call to the fork system call, creating a new process; we are now multitasking. The original (parent) process becomes the “idle process” which is executed whenever there are no processes ready to run. The child process (which has process id 1) calls the program init. (It actually looks in a number of places, including /etc/init, /bin/init, /sbin/init, /etc/rc, and finally /bin/sh.) The init program then starts up all of the initial system processes such as getty and other daemons, and shortly we have a login prompt on the console.
There are a number of important options that can be set when compiling the Linux kernel. These include the root device, swap device, and VGA video mode. The toplevel Makefile allows setting most of these.
The problem with this method is that recompiling the kernel is somewhat time-consuming (at least on my machine; do you have a 100MHz Pentium?). You must also modify the standard Makefile, and remember to continue to do so when upgrading to newer kernels.
The rdev command was written long ago to make it easier to set some of these important kernel options without a recompile. The program directly patches the appropriate variables in a kernel image. These are at fixed addresses (defined in boot/bootsect.S).
While using rdev is fast, it is still somewhat inconvenient in that you have to remember to run it after building each kernel. It is also limited in the options that can be changed. We can do better.
|Where's That Pesky Hidden Word?||Aug 28, 2015|
|A Project to Guarantee Better Security for Open-Source Projects||Aug 27, 2015|
|Concerning Containers' Connections: on Docker Networking||Aug 26, 2015|
|My Network Go-Bag||Aug 24, 2015|
|Doing Astronomy with Python||Aug 19, 2015|
|Build a “Virtual SuperComputer” with Process Virtualization||Aug 18, 2015|
- Concerning Containers' Connections: on Docker Networking
- Problems with Ubuntu's Software Center and How Canonical Plans to Fix Them
- A Project to Guarantee Better Security for Open-Source Projects
- Where's That Pesky Hidden Word?
- Firefox Security Exploit Targets Linux Users and Web Developers
- My Network Go-Bag
- Doing Astronomy with Python
- Build a “Virtual SuperComputer” with Process Virtualization
- Three More Lessons
- diff -u: What's New in Kernel Development