Modules loading preferences fix

Rerwin (Richard) has posted this message to the Puppy 431 bugs thread:

Reports of unreliable handling of module preferences, as given in the BootManager Preference option, probably resulted from a bug in the pup_event_backend_modprobe script, which is responsible for the loading of appropriate hardware driver modules. The attached package, pup_event_backend_modprobe_fix_to_p43x-1.pet, resolves that bug and extends the capabilities of the Preference function to (1) provide predictable control over module preferences and (2) support some special cases of module selection and substitution.

The current implementation of preferences not only can fail to make a substitution, but may load a module other than the one specified, if more than one alternative is appropriate. Specifying the name of a module as a substitute merely results in substitution with whatever module is available for the device; if there are multiple candidates available, the one loaded may not be the one named as the preference.

This new version of the script extends the preference function by (1) allowing multiple preferences for the same module (separated by a "|" and ordered first-choice-first if needed), the selection being governed by the particular modules that identify themselves as supporting a particular device, and (2) allowing dynamic activation of a set of preferences needed when certain conditions occur. The special preferences reside in /etc/rc.d/MODULESCONFIG as assignment statements setting variables named PREF...; they are not accessible through the BootManager.

One use of these extensions is for hybrid USB storage-modem devices (e.g., wireless modems), which require two drivers but only one of them normally gets loaded. All such devices may initially require module usb-storage, then need one of several possible modem drivers. If the normally-loaded driver is usb-storage instead of the others, an internally activated preference is used if usb-storage is already loaded (which it normally is), but the modem driver must be the one(s) intended for the modem (known at load time).

Another use is for supporting ALSA modems that might instead actually be Conexant modems. The Conexant (Linuxant) driver issues an error message if the modem is not a Conexant. In this case, preferences can be activated to force use of the alternate (ALSA) driver after a reboot of Puppy. The new features could support other special module-loading situations as they become known.

This package/dotpet has been tested with all three kernel versions of Puppy 4.3.1. It should be installed by anyone experiencing a problem with preferred modules not loading (e.g., atl1e instead of atl1c). Do not use this package on Puppies 4.1.x or 4.2.x; instead, use the similar, but bugfix-only package created for those Puppies and available in the Bugs/Fixes threads for 4.1.2 and 4.2.1. Use of the HSF/ALSA reselection requires installation of the new modem "fix pack" package (to be uploaded soon in this thread). This fix can be applied to any Puppy 4.3 installation and is a candidate for inclusion in 4.4CE.

I have applied rerwin's fixes to Woof. The affected files are /sbin/pup_event_backend_modprobe, /etc/rc.d/MODULESCONFIG and /etc/rc.d/rc.sysinit.

I will probably upload the latest Woof later today.

Tags: woof