[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH (stage1)] Rework module loading



On Sat, 2007-12-15 at 00:39 -0500, Bill Nottingham wrote: 
> One of the things that anaconda uses kudzu for is determining the list
> of modules to load. This patch fixes that, along with doing a variety
> of other things, determined by the following logic:
> 
> - We want to move to a model where we just load modules from the
> normal information and aliases exported in sysfs
> - This means that we are loading (generally) by modalias, not by
> module name
> - Ergo, we need to either duplicate all the alias handling, sysfs
> walking, etc. in anaconda...
> - Or, we use the system modprobe and udev coldplug. (That is what
> this implements.)

jcm had said he was going to get a libmodprobe, but I suspect that's not
likely to happen in a timely fashion :-/   

> - To use the system modprobe, we either need to hack it to understand
> the cpio module ball...
> - Or, we move to just shipping a normal tree of modules. (That is
> what this implements.)

This is definitely the right thing to do -- now that the initrd is a
compressed cpio ball, sticking another compressed cpio ball inside of it
doesn't really help us that much.  And this definitely makes a number of
things easire to have working

> - To do so, either we need a special static version of modprobe...
> - Or, we switch to a dynamic stage 1 (That is what this implements.)

Don't feel that strongly one way or another -- dynamic gives us the
ability for some nice things (we could always stick busybox there and
have the shell uber-early always for debugging).  And once you get more
than ~ 2 static binaries, you start to lose the size war

> - Passing module options on the commandline is still supported

Given that we write out /etc/modprobe.d/anaconda, does it then make
sense to switch to copying that over to the installed system rather than
the fun around /tmp/modprobe.conf?

> - blacklist=<foo> is now supported, to blacklist automatic loading of
> a particular module

How does blacklisting interact with manually selecting the same module?

> - 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...

> - Manual driver selection is still allowed, if necessary.
> 
> Things not yet modified/fixed in this patchset:
> - Manual driver selection is aborting in newt somewhere. May be
> unrelated.

Should be easier to debug with a dynamic loader, right?  We could even
have an easy to use gdb again!

> - Driver disks are not modified to the new tree layout. Basically,
> they should now be extracted and copied to
> /lib/modules/$(whatever)/updates/. Some tweaks with depmod may be
> necessary to get the aliases in the right place.

Does this mean we'll need to run depmod at installer runtime?  Or can we
just concatenate the alias and deps files?

> 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. 

> Zee diffstat:

Patches look reasonable although things won't work at every step of the
way (eg, buildinstall.functions is added in patch5, but used in the
first one).  But that's okay.  

Jeremy


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]