Messages in this thread | | | Date | Wed, 11 May 2005 03:11:03 +0200 | From | Erik van Konijnenburg <> | Subject | Re: [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/
| |