revisit: turning some of the "always used" modules to built-in

[Peter Jones]

Dave Jones wrote:
> On Sun, Jun 22, 2008 at 11:42:18AM -0700, Arjan van de Ven wrote:
> 
>  > Category 1: Always loaded anyway 
>  > --------------------------------
>  > Rationale: Since we load these always anyway, why bother making it modules
>  > - ata_generic, pata_acpi
> 
> These ones make me hrmm a bit. I'd like to know that our initrd isn't
> going to do something silly before we change these. Peter ?

We probably need to do a little bit of mkinitrd work to make sure this 
works, but not much.

That being said, don't we need to install e.g. ahci _before_ ata_generic 
on most systems to get the right behavior?  Also, how does ata_generic 
interact with ata_piix?  I know changing the install order of ahci vs 
ata_piix causes major flux in behavior...

>  > - libata
> 
> Sure. Done in CVS.
> 
>  > - sg, sd_mod
> 
> Ditto.

sr_mod and cdrom?  They're not strictly required, but it's really, 
really common.  It's 60k of bloat, which isn't great, but I think it 
also makes booting incrementally quicker (because hal won't need to load 
the modules.)

>  > , scsi_mod
> 
> This one is tricky. It seems to become modular because it's dependant upon
> the bool SCSI_NETLINK. A bunch of other scsi modules enable SCSI_NETLINK,
> like the fibrechannel stuff.  I'm not convinced we want to build all that
> stuff in.

Then we need to make sure that there's a dep chain that shows up with 
"modprobe --show-depends".

>  > - ext3, jbd, mbcache
> 
> I'm torn on these. Mostly for the reasons both Eric and Matt suggested.
> The flipside being that Eric knows how to build his own kernels, and can do so,
> but at the same time, if it means he spends less time fixing ext bugs each
> day and more time staring at compiler output, I'm not sure it's a net win.
> Matts argument, whilst RHEL specific, does have an element of validity
> for Fedora too.  We always push the 'Fedora isn't a test vehicle for RHEL'
> angle, but at the same time, there's no denying that doing something completely
> different does take away a certain amount of 'in the field' testing.
> (In this case, I'm primarily thinking about the knock-on effects changes
> like this have on the kernel periphery packages like mkinitrd/anaconda
> which now have to support two separate cases).

Actually, I don't think these three change mkinitrd/anaconda much at 
all; we always pull these three modules in as dependencies, never manually.

>  > Category 2: Always loaded in default install
[...]

>  > - dm_mod
> 
> Yeah, I guess.

This will require minor changes to mkinitrd, but I'm for it.  Also, 
dm_snapshot, since we also always load it (there's no way to tell if 
it's necessary ahead of time :/ )

Also, though not strictly _required_,  dm_zero, and dm_mirror would be 
nice -- you always get them loaded, and there aren't any module  deps on 
them.  (Though arguably this is a deficiency in lvm2)

>  > - ahci (default storage for all new systems; means that there the system 
>  >         always has the / device driver)
> 
> Same thing as above. The mkinitrd logic surrounding ordering of storage
> modules is fragile at best..

I think this will break some ICH[789] boxes, won't it?  I've seen this 
cause ata_piix badly misbehave if this is already loaded when it loads 
on systems configured in "legacy" mode in the BIOS (which is often not 
exposed as an option to the user AT ALL)

>  > - ehci_hcd (means you have a USB keyboard early)
> 
> ISTR there was some issue with this. I'm sure we even tried it once
> in the FC2 era.  Lets give it a shot, and see what happens.

I think this should work these days... if not, we should really just sit 
down and fix it.  There's some mkinitrd work here, but it's mostly just 
code removal, and you should get a working initrd even before we do it.

Also this is required to do usb-serial console (though that's still 
pretty broken itself ATM), which could eventually be really useful for 
debugging.

I think we also want uhci_hcd here; if you've got EHCI you'll wind up 
loading it anyway, and if you don't, then you'll probably want it loaded.

-- 
   Peter