From: Rusty Russell <rusty@rustcorp.com.au>
To: Olaf Hering <olh@suse.de>
Cc: Hollis Blanchard <hollisb@us.ibm.com>,
Dave Boutcher <boutcher@us.ibm.com>,
linuxppc64-dev@lists.linuxppc.org,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
Greg KH <greg@kroah.com>
Subject: Re: module.viomap support for ppc64
Date: Fri, 20 Aug 2004 17:25:46 +1000 [thread overview]
Message-ID: <1092986745.28849.343.camel@bach> (raw)
In-Reply-To: <20040820055741.GA16519@suse.de>
On Fri, 2004-08-20 at 15:57, Olaf Hering wrote:
> On Fri, Aug 20, Rusty Russell wrote:
>
> > Current implementation of aliases is to load one at random: multiple
> > alias resolution is undefined because noone knew what we should do (load
> > them all? Load until one succeeds?). But note that that the base
> > config file overrides anything extracted from the modules themselves, so
> > users/distributions can always specify an exact match.
>
> How is the blacklist stuff supposed to work then? It must be possible
> to map an alias entry to a list of modules, and check if any of them is
> blacklisted. Then just 'for i in $DRIVERS ; do modprobe $i ; done'.
Olaf, I'm trying to understand the problem. We currently have a system
where modprobe resolves aliases, and that's good because it allows users
to override those aliases. We could have a "modprobe --resolve-aliases"
function, but that breaks down if the user puts in an install command,
which they should be able to do.
Looking through SLES and my Debian system, I see:
1) Modules which never want autoloading (eg. evbug)
2) Modules which defer to other modules (eg. de4x5)
3) Modules for which you want to suppress autoloading altogether because
they cause problems, or are handled by other subsystems.
For (1), the information should be contained in the module itself. This
will involve a kernel patch.
For (2), the information should be placed in /etc/modprobe.d/ overriding
those aliases the preferred way.
For (3), modprobe cannot have this in a config file, because what needs
to be blacklisted depends on who is invoking modprobe. For example,
there's a comment that ISDN modules on SuSE are not handled by hotplug,
but /etc/init.d/isdn.
So, a solution would be:
a) A "MODULE_NO_TABLES" macro which suppresses ID table alias
generation,
b) A -X argument to modprobe which says "don't load these modules", and
c) Change modprobe to load all the aliases which match, not just one? I
hadn't done this because I wasn't aware of anything which needed it: is
there something?
I think we're getting there: sorry if I seem a bit obtuse...
Rusty.
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
prev parent reply other threads:[~2004-08-20 7:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-12 17:37 module.viomap support for ppc64 Olaf Hering
2004-08-12 19:34 ` Hollis Blanchard
2004-08-12 23:43 ` Rusty Russell
2004-08-13 9:40 ` Olaf Hering
2004-08-13 13:42 ` Rusty Russell
2004-08-13 20:22 ` Marcelo Tosatti
2004-08-19 21:28 ` Olaf Hering
2004-08-20 3:47 ` Rusty Russell
2004-08-20 5:57 ` Olaf Hering
2004-08-20 7:25 ` Rusty Russell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1092986745.28849.343.camel@bach \
--to=rusty@rustcorp.com.au \
--cc=boutcher@us.ibm.com \
--cc=greg@kroah.com \
--cc=hollisb@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.org \
--cc=olh@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox