On Mon, 2007-12-17 at 23:00 -0500, Bill Nottingham wrote: > Jeremy Katz (katzj@xxxxxxxxxx) 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 _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
