Dan Aloni wrote:
quoted text
> On Sun, May 13, 2007 at 09:23:52AM -0700, Stephen Hemminger wrote:
>> On Sun, 13 May 2007 16:25:17 +0300
>> Dan Aloni <da-x@monatomic.org> wrote:
>>
>>> Kernel developers might find it useful for quickly getting out from some 
>>> rough debugging scenarios.
>>>
>>> Signed-off-by: Dan Aloni <da-x@monatomic.org>
>>>
>> There is already the modprobe blacklist ability in user space.
> 
> Yes, however the point here is that you can easily (and temporarily)
> blacklist a module *manually* from the boot loader without needing to 
> actually perform a complete and successful boot. Using modprobe's 
> blacklist requires editing /etc files, and it also doesn't apply 
> for initrd/initramfs or other system/distribution-specific scripts 
> that would do hardcoded sequential insmod invocations (for example
> on embedded systems that require minimal userspace complexity).

There are two issues (IMHO anyway), both are userspace.

First is the ability blacklist the given module from bootloader.
My initramfs has it since the beginning - it allows a noload=xxx
paramerer (comma-separated list of module patterns, cumulative),
for exactly this purpose.  I implemented modprobe in shell (not
using a binary from module-init-tools) for initramfs (it's some
20 lines of shell code).  Because of exactly that reason - on
certain systems i had a problem with certain drivers, resulting
in boot failures.  Later on, this set of modules gets transformed
into a modprobe blacklist list.  It's trivial to do.

And second is what to do with direct insmod invocations in minimal
embedded system startup sequence.  Well, minimal it or not, but
shell is present anyhow, so I don't see any problem with that,
either...

Just my $0.02...

/mjt
-
unsubscribe notice
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/