This section gives some examples of software that can be used to pass kernel boot-time arguments to the kernel itself. It also gives you an idea of how the arguments are processed, what limitations there are on the boot args, and how they filter down to each appropriate device that they are intended for.
It is important to note that spaces should not be used in a boot argument, but only between separate arguments. A list of values that are for a single argument are to be separated with a comma between the values, and again without any spaces. See the following examples below.
ether=9,0x300,0xd0000,0xd4000,eth0 root=/dev/hda1 *RIGHT*
ether = 9, 0x300, 0xd0000, 0xd4000, eth0 root = /dev/hda1 *WRONG*
Once the Linux kernel is up and running, one can view the command line arguments that were in place at boot by simply typing cat /proc/cmdline at a shell prompt.
When giving examples of boot arguments for device drivers you will commonly see the following given as parameters where numbers matching your particular system will need to be used.
io or iobase -- the first I/O port that the device occupies. These are specified in hexidecimal notation, and usually lie in the range from 0x200 to 0x3ff for ISA devices. Lower case is usually used in hex numbers with Linux.
irq -- the hardware interrupt that the device is configured to use. Valid values will be dependent on the card in question, but will usually be 5, 7, 9, 10, 11, 12, and 15. The other values are usually used for common peripherals like IDE hard disks, floppies, serial ports, etc.
dma -- the DMA (Direct Memory Access) channel that the card may use. Typically only applies to bus-mastering cards. PCI and VLB cards are native bus-masters, and do not require and ISA DMA channel. Some sound cards use two DMA channels, an 8 bit one and a 16 bit one.
The LILO program (LInux LOader) written by Werner Almesberger is the most commonly used. It has the ability to boot various kernels, and stores the configuration information in a plain text file. Most distributions ship with LILO as the default boot-loader. LILO can boot DOS, OS/2, Linux, FreeBSD, etc. without any difficulties, and is quite flexible.
A typical configuration will have LILO stop and print LILO: shortly after you turn on your computer. It will then wait for a few seconds for any optional input from the user, and failing that it will then boot the default system. Typical system labels that people use in the LILO configuration files are linux and backup and msdos. If you want to type in a boot argument, you type it in here, after typing in the system label that you want LILO to boot from, as shown in the example below.
LILO: linux root=/dev/hda1
LILO comes with excellent documentation, and for the purposes of boot args discussed here, the LILO append= command is of significant importance when one wants to add a boot time argument as a permanent addition to the LILO config file. You simply add something like append = "foo=bar" to the /etc/lilo.conf file. It can either be added at the top of the config file, making it apply to all sections, or to a single system section by adding it inside an image= section. Please see the LILO documentation for a more complete description.
The other commonly used Linux loader is `LoadLin' which is a DOS program that has the capability to launch a Linux kernel from the DOS prompt (with boot-args) assuming that certain resources are available. This is good for people that use DOS and want to launch into Linux from DOS.
It is also very useful if you have certain hardware which relies on the supplied DOS driver to put the hardware into a known state. A common example is `SoundBlaster Compatible' sound cards that require the DOS driver to set a few proprietary registers to put the card into a SB compatible mode. Booting DOS with the supplied driver, and then loading Linux from the DOS prompt with LOADLIN.EXE avoids the reset of the card that happens if one rebooted instead. Thus the card is left in a SB compatible mode and hence is useable under Linux.
There are also other programs that can be used to boot Linux. For a complete list, please look at the programs available on your local Linux ftp mirror, under system/Linux-boot/.
There are a few of the kernel boot parameters that have their default values stored in various bytes in the kernel image itself. There is a utility called rdev that is installed on most systems that knows where these values are, and how to change them. It can also change things that have no kernel boot argument equivalent, such as the default video mode used.
The rdev utility is usually also aliased to swapdev, ramsize, vidmode and rootflags. These are the five things that rdev can change, those being the root device, the swap device, the RAM disk parameters, the default video mode, and the readonly/readwrite setting of root device.
More information on rdev can be found by typing rdev -h or by reading the supplied man page (man rdev).
Most of the boot args take the form of:
name[=value_1][,value_2]...[,value_11]
where `name' is a unique keyword that is used to identify what part of the kernel the associated values (if any) are to be given to. Multiple boot args are just a space separated list of the above format. Note the limit of 11 is real, as the present code only handles 11 comma separated parameters per keyword. (However, you can re-use the same keyword with up to an additional 11 parameters in unusually complicated situations, assuming the setup function supports it.) Also note that the kernel splits the list into a maximum of ten integer arguments, and a following string, so you can't really supply 11 integers unless you convert the 11th arg from a string to an int in the driver itself.
Most of the sorting goes on in linux/init/main.c. First, the kernel checks to see if the argument is any of the special arguments `root=', `ro', `rw', or `debug'. The meaning of these special arguments is described further on in the document.
Then it walks a list of setup functions (contained in the bootsetups array) to see if the specified argument string (such as `foo') has been associated with a setup function (foo_setup()) for a particular device or part of the kernel. If you passed the kernel the line foo=3,4,5,6,bar then the kernel would search the bootsetups array to see if `foo' was registered. If it was, then it would call the setup function associated with `foo' (foo_setup()) and hand it the integer arguments 3, 4, 5 and 6 as given on the kernel command line, and also hand it the string argument bar.
Anything of the form `foo=bar' that is not accepted as a setup function as described above is then interpreted as an environment variable to be set. An example would be to use TERM=vt100 or BOOT_IMAGE=vmlinuz.bak as a boot argument. These environment variables are typically tested for in the initialization scripts to enable or disable a wide range of things.
Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto process one, which is usually the init program. The most common argument that is passed to the init process is the word single which instructs init to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init installed on your system to see what arguments it accepts.