Description of problem: RHEL5 includes the ability for driver (module) prioritization, for the first time. It is possible to specify that a module of a specific name should be favored from one location (an update path) over a built-in module. Unfortunately, this does not extend to PCI ID information and other datums used during module load of certain third party drivers. It is proposed to extend the module override functionality so that one can specific "override this in-kernel module of name foo with my module of name bar". In such cases, the in-kernel module will no longer be available *at all*, and it is presumed that its functionality is entirely replaced. This is an unsupported operation, but it is one that we have been asked to consider providing infrastructure for - even though we won't support it officially.
what about: blacklist old-module
What are the support implications?
From an engineering perspective, the user is at that point replacing a supported Red Hat driver an unsupported closed source module. Red Hat does not support such configurations, because we cannot debug closed source drivers. As shown by past experience, closed source drivers can and do corrupt other parts of the system. We always tell people to unload closed source drivers before producing a problem, so that we eliminate variables we cannot debug. The mechanisms ALREADY EXIST in the module loading area to allow people to override Red Hat drivers with unsupported ones: (1) update modprobe.conf or (2) use /etc/modprobe.d/blacklist. So AFAICS the only remaining problem Red Hat must concern itself with is making sure that people can override Red Hat drivers at install time.
I was thinking about using blacklist *but* ideally we'd have a command that blacklisted only those PCI (or other modalias) entries provided by the "replacement" driver. What do you folks think? Jon.
IMO it is far easier for the user to figure out that he wants to avoid driver FOO, than avoiding PCI ID 1234:5478. Here again, this is ONLY an installer/anaconda/kudzu/hwdata issue. The tools that read the PCI ID maps, load the drivers for the first time, and write /etc/modprobe.conf are the ones that must know to prefer the replacement driver to the RH-shipped driver. Once modprobe.conf points at the replacement driver, everything works as it should, reboot after reboot after reboot.
Make that "once modprobe.conf AND INITRD point at the replacement driver[...]"
We have handled this problem in the past using a shell script on the driver update disk. I see no problem doing that in the future as well. The only problem is that users currently need to switch to the shell console, mout the DUD and start the setup script manually. It'd be a very convenient feature to have one ore more hooks on the DUD (a pre-installation and post-installation script, say) that would be called by anaconda automatically at specific points during the installation if a DUD with such scripts is present. That would greatly simplify the installation procedure in a system that needs 3rd party drivers, with little effort on Red Hat's part.
mkinitrd doesn't necessarily use aliases in modprobe.conf - it uses the same modprobe alias matching as udev.
This is already possible using a combination of overriding and blacklisting. My intention is to document that process and offer advice as needed - the longer term solution is to support driver rebinding upstream in Fedora and have that in place for a future release of RHEL. That will allow many different drivers for the same PCI ID, and allow to easily specific which one is used, at run time. Jon.
Please provide us the steps to override the in-box driver with the DUD driver at install? Prefer to capture the steps here as well as in any other document. RP
Yes, how can I specify blacklist entries on the DUD?
Any feedback to the questions asked in comments #15 and #16? Thanks.
Feedback from Jon: You would need to use a kmod style DuD, and put the updated modprobe configuration ".d" file into the RPM.
------- Comment From pair.com 2008-01-23 15:11 EDT------- I verified the behavior with by generating a DUD with 0.9.9 version of the ddiskit available at http://dup.et.redhat.com/ddiskit/ It was successful both on rhel5 and on rhel5.1 the inbox driver got overriden by the DUD driver. So we can close this one. Misc info: On rhel5 the driver in the rpm got installed in the updates directory, but the rpm did not get installed. On rhel5.1 the rpm as well as the driver got installed. the driver got installed in extras directory.