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.
|Simple Ways to Add Security to Web Development||Mar 14, 2014|
|Android Candy: Humans, Run!||Mar 12, 2014|
|Alice, the Turtle of the Modern Age||Mar 07, 2014|
|Using Django and MongoDB to Build a Blog||Mar 05, 2014|
|What virtualization solution do you use/manage at work?||Mar 04, 2014|
|Our Assignment||Mar 04, 2014|
- Simple Ways to Add Security to Web Development
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Returning to Ground from the Web's Clouds
- New Products
- Zato—Agile ESB, SOA, REST and Cloud Integrations in Python
- Sign Up to Win a Silicon Mechanics Swag Pack!
- You have to be careful there
2 weeks 4 days ago
- Wonder when LJ is going to
2 weeks 4 days ago
- Puerto Rico Free Software
2 weeks 5 days ago
2 weeks 6 days ago
- I hate voice commands
3 weeks 11 hours ago
- usabilty --- AGAIN with this nonsense
3 weeks 13 hours ago
- Don't make excuses
3 weeks 16 hours ago
- Sorry to let you know, but
3 weeks 17 hours ago
- Ridiculous statement. Not a
3 weeks 1 day ago
3 weeks 1 day ago