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
_______________________________________________
Fedora-kernel-list mailing list
Fedora-kernel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-kernel-list
