Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 233992

Summary: FEAT: [RHEL5.2]: overriding of built-in kernel modules
Product: Red Hat Enterprise Linux 5 Reporter: Jon Masters <jcm>
Component: module-init-toolsAssignee: Jon Masters <jcm>
Status: CLOSED WONTFIX QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 5.0CC: agospoda, andriusb, coughlan, harald, james.smart, jamie.wellnitz, jgarzik, jgiles, jjarvis, kanderso, katzj, konradr, ktokunag, lcm, linville, ltroan, mark_salyzyn, martin.wilck, mbarrow, nobody+pnasrat, notting, pjones, prarit, rkenna, sdenham, sreenivas.bagalkote, tburke, tom_white, zaitcev
Target Milestone: betaKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-10-22 02:13:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 216992, 217105, 217217, 221446, 227737, 249266, 276501, 296431, 372911    

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
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.

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?

Jon.


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.

Jon.

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.

RP

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 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.