Re: [PATCH (stage1)] Rework module loading

[Jeremy Katz <katzj redhat com>]

On Mon, 2007-12-17 at 23:00 -0500, Bill Nottingham wrote:
> Jeremy Katz (katzj redhat com) said: 
> > > - blacklist=<foo> is now supported, to blacklist automatic loading of
> > > a particular module
> > 
> > How does blacklisting interact with manually selecting the same module?
> 
> blacklisting means 'ignore any aliases for this module'. So it will
> never get loaded by net-pf-<whatever> or pci:<whatever> aliases, but
> can still be loaded directly by hand.

That's what I _thought_ happened, but I remembered something weird there
at one point.  I'll just chalk it up to not remembering correctly.

> > > - nofirewire, nousb, etc. are ignored. The only noXX handled is
> > > 'noprobe', which disables udev coldplug entirely.
> > 
> > Having some of these back would be really useful -- the fact that we can
> > just not probe a specific problematic subsystem is regularly more useful
> > than having to push people through loading every driver manually.
> > Especially when you have a USB keyboard...
> 
> The simple way to do this would be to boot with blacklist=firewire-ohci,
> or similar. If we want to automatically map a couple of old common options
> to this, we could, but I don't think it's the right way to handle this
> for new things. (After all, fix the kernel!).

While not great or perfect, it's commonly used.  It's also used quite a
bit for people that want to load drivers in a specific order so their
drives show up with specific names.

Also, it looks like we lost the late load of modules for loading the
various fiberchannel stuff last.

> > > Size concerns:
> > > Before: 7.2MB
> > > After: 8.6MB 
> > 
> > What's the memory overhead of not having the modules compressed "on
> > disk"?  du -sh of the uncompressed initramfs vs the old should give a
> > reasonable idea here. 
> 
> F8: 9.4MB
> This: 29.7MB
> 
> 17.3MB of the 20.3MB difference is in the modules tree.

Crap, that's a pretty sizable overhead.  I wonder if there's a chance of
getting some support in module-init-tools for some form of "keeping
modules around in a compressed form" :-/

Jeremy