Some devices require a bit of extra configuration beyond the
normal aliasing of a device to a module.
Hardware devices are usually identified through their
major device numbers, e.g. ftape is
char-major-27. However, if you look through
the entries in /dev for char major 10,
you will see that this is a bunch of very different devices,
including
These devices are controlled by several different
modules, not a single one, and therefore the kerneld
configuration for these misc. devices
use the major number and the minor
number:
alias char-major-10-1 psaux # For PS/2 mouse
alias char-major-10-130 wdt # For WDT watchdog |
You need a kernel version 1.3.82 or later to use this;
earlier versions do not pass the minor number to kerneld,
making it impossible for kerneld to figure out which of the
misc. device modules to load.
Drivers for SCSI devices consist of a driver for the
SCSI host adapter (e.g. an Adaptec 1542), and a driver for the
type of SCSI device you use, e.g. a hard disk, a CD-ROM or a
tape-drive. All of these can be loaded as modules. However,
when you want to access e.g. the CD-ROM drive that is
connected to the Adaptec card, the kernel and kerneld only
knows that it needs to load the sr_mod
module in order to support SCSI CD-ROM's; it does not know
what SCSI controller the CD-ROM is connected to, and hence
does not know what module to load to support the SCSI
controller.
To resolve this, you can add an entry for the SCSI
driver module to your /etc/conf.modules
that tells kerneld which of the many possible SCSI controller
modules it should load:
alias scd0 sr_mod # sr_mod for SCSI CD-ROM's ...
alias scsi_hostadapter aha1542 # ... need the Adaptec driver |
This only works with kernel version 1.3.82 or later.
This works if you have only one SCSI controller. If you
have more than one, things become a little more
difficult.
In general, you cannot have kerneld load a driver for a
SCSI host adapter, if a driver for another host adapter is
already installed. You must either build both drivers into
your kernel (not as modules), or load the modules
manually.
Tip: There is a way that you can
have kerneld load multiple SCSI drivers. James Tsiao came up
with this idea:
You can easily have kerneld load the second scsi
driver by setting up the dependency in your modules.dep by
hand. You just need an entry like:
/lib/modules/2.0.30/scsi/st.o: /lib/modules/2.0.30/scsi/aha1542.o |
To have kerneld load the
aha1542.o before it loads
st.o. My machine at home is set up
almost exactly like the setup above, and it works fine for
all my secondary scsi devices, including tape, cd-rom, and
generic scsi devices. The drawback is that
depmod -a can't autodetect these
dependencies, so the user needs to add them by hand, and
not run depmod -a on boot up. But once
it is set up, kerneld will autoload the
aha1542.o just
fine.
You should be aware, that this technique only works if
you have different kinds of SCSI devices on the two
controllers, for example, hard disks on one controller, and
cd-rom drives, tapes or generic SCSI devices on another.
Sometimes, just loading the module is not enough to get
things working. For instance, if you have your sound card
compiled as a module, it is often convenient to set a certain
volume level. Only problem is, the setting vanishes the next
time the module is loaded. Here is a neat trick from Ben
Galliart (<bgallia@luc.edu>):
The final solution required installing the setmix package and then
adding the following line to my
/etc/conf.modules:
post-install sound /usr/local/bin/setmix -f /etc/volume.conf |
What this does is that after the sound module is loaded,
kerneld runs the command indicated by the
post-install sound entry. So the sound
module gets configured with the command
/usr/local/bin/setmix -f
/etc/volume.conf.
This may be useful for other modules as well, for
example the lp module can be configured
with the tunelp program by adding
post-install lp tunelp options |
For kerneld to recognize these options, you will need a
version of kerneld that is 1.3.69f or later.
Note: An earlier version of this mini-HOWTO mentioned a
pre-remove option, that might be used to run a command just
before kerneld removed a module. However, this has never
worked and its use is therefore discouraged - most likely,
this option will disappear in a future kerneld release. The
whole issue of module settings is undergoing some change at
the moment, and may look different on your system by the
time you read this.