Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 233992 - FEAT: [RHEL5.2]: overriding of built-in kernel modules
Summary: FEAT: [RHEL5.2]: overriding of built-in kernel modules
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: module-init-tools
Version: 5.0
Hardware: All
OS: Linux
Target Milestone: beta
: ---
Assignee: Jon Masters
QA Contact:
Depends On:
Blocks: 249266
TreeView+ depends on / blocked
Reported: 2007-03-26 15:27 UTC by Jon Masters
Modified: 2008-01-23 20:16 UTC (History)
29 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2007-10-22 02:13:04 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
IBM Linux Technology Center 38935 None None None Never

Description Jon Masters 2007-03-26 15:27:01 UTC
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.

Comment 3 Harald Hoyer 2007-03-27 08:40:05 UTC
what about:
blacklist old-module

Comment 4 Andrius Benokraitis 2007-03-27 17:51:59 UTC
What are the support implications?

Comment 5 Jeff Garzik 2007-03-27 18:16:22 UTC
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)
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.

Comment 6 Jon Masters 2007-03-27 19:13:15 UTC
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?


Comment 7 Jeff Garzik 2007-03-27 19:30:18 UTC
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.

Comment 8 Jeff Garzik 2007-03-27 19:34:17 UTC
Make that "once modprobe.conf AND INITRD point at the replacement driver[...]"

Comment 9 Martin Wilck 2007-03-28 08:09:40 UTC
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.

Comment 10 Bill Nottingham 2007-03-30 05:59:10 UTC
mkinitrd doesn't necessarily use aliases in modprobe.conf - it uses the same
modprobe alias matching as udev.

Comment 14 Jon Masters 2007-10-22 02:13:04 UTC
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.


Comment 15 Ram Pai 2007-11-14 21:33:46 UTC
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.


Comment 16 Martin Wilck 2007-11-15 08:00:57 UTC
Yes, how can I specify blacklist entries on the DUD?

Comment 17 Chris McDermott 2007-11-27 22:46:49 UTC
Any feedback to the questions asked in comments #15 and #16? Thanks.

Comment 18 John Jarvis 2007-12-12 19:08:32 UTC
Feedback from Jon:  You would need to use a kmod style DuD, and put the updated
modprobe configuration ".d" file into the RPM.

Comment 19 IBM Bug Proxy 2008-01-23 20:16:26 UTC
------- Comment From 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

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.

Note You need to log in before you can comment on or make changes to this bug.