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

Re: [PATCH (stage1)] Rework module loading



On Mon, 2007-12-17 at 23:19 -0500, Bill Nottingham wrote:
> Jeremy Katz (katzj redhat com) said: 
> > 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.
> 
> Drive ordering is ephemeral. LABEL=/UUID= is your friend.

LABEL/UUID don't really help when you have blank disks that you're just
installing on for the first time...

> > > > > 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" :-/
> 
> You can gzip modules. That cuts it down to 14.9MB. Note that there's no
> firmware on either this or the F8 disc, and that's not going to be compressed
> once it's added.

gzip it is then!  And actually, the firmware can be compressed, at least
as long as we're using our own firmware loader.  And then if we want to
switch away from our firmware loading, then we can add support for
compressed firmware to the udev firmware loader.

Jeremy


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