Some devices require a bit of extra configuration beyond the normal aliasing of a device to a module.
Character devices on major number 10: The miscellaneous devices
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
Mice of various sorts (bus mice, PS/2 mice)
Watchdog devices
The kernel random device
APM (Advanced Power Management) interface
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:
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 (<>):
The final solution required installing the setmix package and then adding the following line to my /etc/conf.modules:
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.