Re: [PATCH (stage1)] Rework module loading

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

 



On Mon, 2007-12-17 at 23:30 -0500, Bill Nottingham wrote:
> Jeremy Katz (katzj@xxxxxxxxxx) 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...
> 
> It's not like the UI would be that much better with the FC disks loaded later -
> there would still be 5 billion of them in the dropdown. They could certainly
> be blacklisted.

It doesn't necessarily help the UI, but it helps with kickstart.  A lot.
Losing this would be a major regression from the point of view of a lot
of large customers

> > > > 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.
> 
> Once you add all the qlogic & wireless firmware, it's not going
> to be small even when compressed.

All the more reason to compress things.  Also, we might be able to get
away with removing firmware and maybe even modules after we've gotten to
the second stage to get back some of the memory overhead here

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux