From: Erik van Konijnenburg <ekonijn@xs4all.nl>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Greg KH <gregkh@suse.de>,
"Alexander E. Patrakov" <patrakov@ums.usu.ru>,
linux-hotplug-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, Roman Kagan <rkagan@mail.ru>
Subject: Re: [PATCH] Re: [ANNOUNCE] hotplug-ng 002 release
Date: Wed, 11 May 2005 09:59:55 +0000 [thread overview]
Message-ID: <20050511115955.D7594@banaan.localdomain> (raw)
In-Reply-To: <1115782753.17201.54.camel@localhost.localdomain>; from rusty@rustcorp.com.au on Wed, May 11, 2005 at 01:39:13PM +1000
On Wed, May 11, 2005 at 01:39:13PM +1000, Rusty Russell wrote:
> On Wed, 2005-05-11 at 03:11 +0200, Erik van Konijnenburg wrote:
> > Here's an alternative approach that should cover these interests:
> > - add a keyword 'blacklist' to the configuration language,
> > that will be interpreted after alias expansion, but before
> > searching modules.dep.
>
> This makes "blacklist X" equivalent to "install X /bin/true" right? i.e
> "ignore it".
Except for output on --show-depends and total number of forks, yes.
Based on comments from Greg and Christian, it would be better to apply
blacklisting only to the result of alias expanding for kernel generated
module maps. So:
cat >> /etc/hotplug/blacklist.d/test <<//
blacklist snd_rme96
//
would apply to
modprobe 'pci:v000010EEd00003FC0sv*sd*bc*sc*i*'
but not to
modprobe snd_rme96
> > Advantages:
> > - it needs a lot less code
> > - distributions can decide whether blacklists work always,
> > never, or only for the kernel simply by playing with which
> > configuration file is used
> > - my initramfs builder does not have to be special cased
> > to know that some install directives really are blacklist
> > directives.
>
> Well, a module mentioned in hotplug's blacklist file would be a pretty
> good candidate for exclusion from your initramfs builder. Existing
> install commands are already trouble for initramfs building, since they
> can do arbitrary things...
Yep. At the moment my initramfs builder aborts on such install directives,
because there's no correct way of handling them. Since install isn't used
all that much and certainly not in boot-critical stuff, thats acceptable,
but if we're going to use install for every blacklisted module,
that's a problem.
> How about I allow "--config=-" and hotplug can use the existing
> blacklists and 'sed'?
That would keep existing blacklist, which is good for Marco and
for initramfs builders.
However, it would be bad for hotplug-ng: one of the strong points
is that it speeds booting by dropping loads of shell code, and
adding sed for blacklist processing does not fit well with that.
I'll take a stab at a patch that introduces the 'blacklist' keyword
to see if that reduces the code enough to make it acceptable.
Regards,
Erik
-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_ids93&alloc_id\x16281&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
next prev parent reply other threads:[~2005-05-11 9:59 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-06 21:22 [ANNOUNCE] hotplug-ng 002 release Greg KH
2005-05-08 22:52 ` Per Liden
2005-05-09 21:13 ` Per Svennerbrandt
2005-05-10 22:17 ` Per Liden
2005-05-10 22:41 ` Greg KH
2005-05-10 23:56 ` Per Liden
2005-05-11 1:22 ` Brian Gerst
2005-05-11 5:33 ` Greg KH
2005-05-18 23:00 ` Per Svennerbrandt
2005-05-18 23:00 ` [PATCH][RFC] __request_module: fixed argument request_module with waitflag Per Svennerbrandt
2005-05-18 23:01 ` [PATCH][RFC] request_modalias: MODALIAS based module loading Per Svennerbrandt
2005-05-18 23:37 ` Per Svennerbrandt
2005-05-10 22:41 ` [ANNOUNCE] hotplug-ng 002 release Greg KH
2005-05-12 21:42 ` Greg KH
2005-05-13 8:19 ` Michael Tokarev
2005-05-13 16:02 ` Greg KH
2005-05-13 23:21 ` Per Svennerbrandt
2005-05-14 5:59 ` Greg KH
2005-05-18 9:27 ` David Weinehall
2005-05-09 23:22 ` Greg KH
2005-05-10 21:51 ` Per Liden
2005-05-11 5:36 ` Greg KH
2005-05-09 3:57 ` Rusty Russell
2005-05-09 23:21 ` Greg KH
2005-05-10 9:29 ` Rusty Russell
2005-05-10 9:43 ` Marco d'Itri
2005-05-10 12:58 ` Alexander E. Patrakov
2005-05-10 17:24 ` Marco d'Itri
2005-05-10 20:13 ` Greg KH
2005-05-10 20:28 ` Lee Revell
2005-05-10 20:59 ` Greg KH
2005-05-10 21:02 ` Marco d'Itri
2005-05-10 20:31 ` Marco d'Itri
2005-05-10 20:52 ` Greg KH
2005-05-10 20:59 ` Bill Nottingham
2005-05-10 21:08 ` Marco d'Itri
2005-05-10 21:22 ` Erik van Konijnenburg
2005-05-10 23:55 ` [PATCH] " Erik van Konijnenburg
2005-05-11 0:05 ` Marco d'Itri
2005-05-11 5:40 ` Greg KH
2005-05-11 0:08 ` [PATCH] " Rusty Russell
2005-05-11 1:11 ` Erik van Konijnenburg
2005-05-11 3:39 ` Rusty Russell
2005-05-11 9:59 ` Erik van Konijnenburg [this message]
2005-05-11 10:52 ` Rusty Russell
2005-05-11 10:58 ` Marco d'Itri
2005-05-11 13:06 ` Erik van Konijnenburg
2005-05-12 4:39 ` Rusty Russell
2005-05-12 7:47 ` Erik van Konijnenburg
2005-05-11 0:01 ` Rusty Russell
2005-05-11 0:10 ` Marco d'Itri
2005-05-11 1:09 ` Rusty Russell
2005-05-11 7:31 ` Christian Zoz
2005-05-14 23:02 ` Michael Tokarev
2005-05-16 19:11 ` Greg KH
2005-05-16 21:24 ` Marco d'Itri
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=20050511115955.D7594@banaan.localdomain \
--to=ekonijn@xs4all.nl \
--cc=gregkh@suse.de \
--cc=linux-hotplug-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=patrakov@ums.usu.ru \
--cc=rkagan@mail.ru \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox