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.025 / U:87.560 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site