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.