Bug 233992 - FEAT: [RHEL5.2]: overriding of built-in kernel modules
FEAT: [RHEL5.2]: overriding of built-in kernel modules
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: module-init-tools (Show other bugs)
5.0
All Linux
medium Severity high
: beta
: ---
Assigned To: Jon Masters
: FutureFeature
Depends On:
Blocks: 216992 217105 217217 221446 227737 249266 276501 296431 372911
  Show dependency treegraph
 
Reported: 2007-03-26 11:27 EDT by Jon Masters
Modified: 2008-01-23 15:16 EST (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-21 22:13:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
IBM Linux Technology Center 38935 None None None Never

  None (edit)
Description Jon Masters 2007-03-26 11:27:01 EDT
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 04:40:05 EDT
what about:
blacklist old-module
Comment 4 Andrius Benokraitis 2007-03-27 13:51:59 EDT
What are the support implications?
Comment 5 Jeff Garzik 2007-03-27 14:16:22 EDT
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 15:13:15 EDT
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 15:30:18 EDT
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 15:34:17 EDT
Make that "once modprobe.conf AND INITRD point at the replacement driver[...]"
Comment 9 Martin Wilck 2007-03-28 04:09:40 EDT
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 01:59:10 EDT
mkinitrd doesn't necessarily use aliases in modprobe.conf - it uses the same
modprobe alias matching as udev.
Comment 14 Jon Masters 2007-10-21 22:13:04 EDT
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 16:33:46 EST
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 03:00:57 EST
Yes, how can I specify blacklist entries on the DUD?
Comment 17 Chris McDermott 2007-11-27 17:46:49 EST
Any feedback to the questions asked in comments #15 and #16? Thanks.
Comment 18 John Jarvis 2007-12-12 14:08:32 EST
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 15:16:26 EST
------- Comment From pair@us.ibm.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.

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