From: Olaf Hering <olh@suse.de>
To: Rusty Russell <rusty@rustcorp.com.au>
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>
Subject: Re: module.viomap support for ppc64
Date: Fri, 20 Aug 2004 07:57:41 +0200 [thread overview]
Message-ID: <20040820055741.GA16519@suse.de> (raw)
In-Reply-To: <1092973671.28849.243.camel@bach>
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'.
> > Is there such functionality for the modules.alias file in
> > module-init-tools? I played around with modprobe -n, but could not
> > figure it out. Unfortunately, some hardware has more than one driver.
> > bcm5700/tg3, eepro100/e100 and maybe more.
>
> OK, I think the difference here is that I feel modprobe should resolve
> it. What's the right answer? Do we need a new "unalias" config cmd
> which does the blacklist, or is the current positive method better? How
> do you currently decide?
modprobe or some other tool can certainly resolve it, but something has
to make a decision based on a blacklist if a certain module can be
loaded.
Look at /etc/hotplug/pci.agent how it currently done, it parses the
modules.pcimap, fills $DRIVERS and passes that variable to the generic
modprobe function from hotplug.functions. It reads
/etc/hotplug/blacklist to decide if any of the modules listed in DRIVERS
must be skipped.
--
USB is for mice, FireWire is for men!
sUse lINUX ag, nÜRNBERG
next prev parent reply other threads:[~2004-08-20 5:57 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 [this message]
2004-08-20 7:25 ` Rusty Russell
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=20040820055741.GA16519@suse.de \
--to=olh@suse.de \
--cc=boutcher@us.ibm.com \
--cc=hollisb@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@lists.linuxppc.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.