Re: [PATCH] Re: [ANNOUNCE] hotplug-ng 002 release

[Erik van Konijnenburg <ekonijn@xs4all.nl>]

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/