lkml.org 
[lkml]   [2005]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Re: [ANNOUNCE] hotplug-ng 002 release
On Wed, May 11, 2005 at 10:08:25AM +1000, Rusty Russell wrote:
> On Wed, 2005-05-11 at 01:55 +0200, Erik van Konijnenburg wrote:
> > Hi,
> >
> > Patch against module-init-tools-3.2-pre4 to ignore modules
> > listed in /etc/hotplug/blacklist or blacklist.d (recursively).
>
> That's a lot of code to make a module impossible to install, and I think
> it kind of misses the point. Surely a non-hotplug "modprobe
> blacklisted-module" should work?
>
> If we define the first install to override included install commands,
> and hotplug uses --config=<blacklistfile>, I think we have a better
> solution.

Lets see:
- You want less code (for good reason, it really is a lot more
than the equivalent in perl)
- Marco wants the blacklist only to work when invoked via kernel,
and needs only /etc/hotplug/blacklist.d.
- Marco wants the blacklist to apply after alias expansion
rather than before.
- I want to avoid install commands whenever possible.
The reason is that for building an initramfs, I need to interpret
modprobe output and decide what goes on the image. For 'insmod'
that's easy; but I don't know of a way to interpret install
command lines and deciding *reliably* what executables and libraries
need to go on the image. (incidentally, this is a use case
where blacklist interpretation is desirable, even though modprobe
is not invoked by the kernel)

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.

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.

If this approach seems workable to you, I plan to build something
like this tomorrow.

> > * tested only with -n, -v and --showdeps, not in live use.
>
> I'm going to start bundling the testsuite with the source, to encourage
> people to actually use it: it's not that hard...

That's a hint I guess ... OK, next patch will go through the suite.

Regards,
Erik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-11 03:15    [W:0.100 / U:0.236 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site