Red Hat Bugzilla – Bug 233992
FEAT: [RHEL5.2]: overriding of built-in kernel modules
Last modified: 2008-01-23 15:16:26 EST
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 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
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)
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?
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.
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
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 email@example.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.
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.