Have you actually tested any of these proposed changes before you come barging in, or even looked for history as to why they're like that? In reality you should send this, with them all separate, with reasons/justification why you believe they should be changed to the kernel list. > Just checked what is in kernel configuration and seems ATA driver IS > compiled statically into the kernel =:-o > Why? Most of the used HW more likely will be using SATA. > It would be really good to change this by: SATA is ATA, there's Parallel and Serial ATA.... part of the same stack within the kernel. > -CONFIG_ATA=y > +CONFIG_ATA=m > > Fedora on mounting initrd is using from maaaany years ramfs (not ext fs). > If you want to debug what happens on mounting even rootfs fs driver > you can use all tools which you may need packing them into initrd. > With grubby now adding such additional tools is incredibly easy thing > to do, and you don't need to have ext compiled into the kernel to > prepare such debug tooling. > You cannot use on recovery ext driver if your crashed hardware > resources does not provide any block device formatted as ext fs vol. > > IPv4 support is not modularised in Linux kernel source code at all so > for now it is not an option to have or not to have IP stack in main > kernel binary like it is on for example Solaris. And yes, it would be > good to have modularise IPv4 support (like it is with IPv6) to handle > scenarios where someone is using only IPv6 but it is matter of some > serious work which needs to be done with rearchitecting few things in > Linux kernel .. not a choosing something in kernel source code > configuration only. > > I've asked about reasons because I'm trying to use everywhere btrfs as > rootfs and for the people using xfs only in similar situations this > ext driver compiled into the kernel is like 1kg lead weight dangling > between the legs .. (especially on some ARM systems with only 256MB > RAM) > IMO looks like only reasons why ext still is compiled into the kernel > are related to the fact that for quite long time no one have been > trying to update kernel source code configuration files and now mamy > drivers are not even enabled as loadable modules. > > Many staging drivers and especially USB HID drivers are not enabled as > well. IRDA, FPGA support is not at all enabled (even as module). > There is many things which can be now provided as module instead be > compiled in to the kernel. > > Few examples after quick review: > 1) gzip support in initrd is enough as grubby is using only gzip. > > CONFIG_RD_GZIP=y > -CONFIG_RD_BZIP2=y > -CONFIG_RD_LZMA=y > -CONFIG_RD_XZ=y > -CONFIG_RD_LZO=y > -CONFIG_RD_LZ4=y > +# CONFIG_RD_BZIP2 is not set > +# CONFIG_RD_LZMA is not set > +# CONFIG_RD_XZ is not set > +# CONFIG_RD_LZO is not set > +# CONFIG_RD_LZ4 is not set > > 2) > -CONFIG_X86_MSR=y > -CONFIG_=y > +CONFIG_X86_MSR=m > +CONFIG_X86_CPUID=m > > 3) > -CONFIG_CPU_FREQ_GOV_POWERSAVE=y > -CONFIG_CPU_FREQ_GOV_USERSPACE=y > +CONFIG_CPU_FREQ_GOV_POWERSAVE=m > +CONFIG_CPU_FREQ_GOV_USERSPACE=m > CONFIG_CPU_FREQ_GOV_ONDEMAND=y > -CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y > +CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m > > 4) I don't think that PCMCIA needs to be hardcoded in to the kernel Historically there's actually reasons why it did actually, have you tested this on older hardware? > -CONFIG_PCCARD=y > -CONFIG_PCMCIA=y > +CONFIG_PCCARD=m > +CONFIG_PCMCIA=m > > 5) especially on x86* or on guest systems working inside VM There's supported HW that needs it built in, again have you looked at list/git history as to why it's like that. > -CONFIG_REGMAP_I2C=y > -CONFIG_REGMAP_SPI=y > +CONFIG_REGMAP_I2C=m > +CONFIG_REGMAP_SPI=m > > 6) if someone is using only SCSI this will be useful > -CONFIG_SATA_AHCI=y > +CONFIG_SATA_AHCI=m > > -CONFIG_ATA_PIIX=y > +CONFIG_ATA_PIIX=m > > 7) > -CONFIG_INPUT_LEDS=y > +CONFIG_INPUT_LEDS=m There's hard dependencies why i2c needs to be built in. > -CONFIG_I2C=y > +CONFIG_I2C=m > > 8) If someone is using Linux working in VM or headless HW .. Actually a lot of VMs have mice mapped by default. > -CONFIG_INPUT_MOUSEDEV=y > +CONFIG_INPUT_MOUSEDEV=m > > -CONFIG_MOUSE_PS2=y > +CONFIG_MOUSE_PS2=m > > (this is useless in case guest system in VM) > -CONFIG_HWMON=y > +CONFIG_HWMON=m The AGP is likely legitimate, it's been disabled on most non x86 arches for some time (I think some old ppc64 systems being the other hold out), although those systems then won't get graphics until much later in the boot process.... > -CONFIG_AGP=y > -CONFIG_AGP_AMD64=y > -CONFIG_AGP_INTEL=y > -CONFIG_AGP_SIS=y > -CONFIG_AGP_VIA=y > -CONFIG_INTEL_GTT=y > +CONFIG_AGP=m > +CONFIG_AGP_AMD64=m > +CONFIG_AGP_INTEL=m > +CONFIG_AGP_SIS=m > +CONFIG_AGP_VIA=m > +CONFIG_INTEL_GTT=m > > -CONFIG_HID_GENERIC=y > +CONFIG_HID_GENERIC=m > > -CONFIG_USB=y > +CONFIG_USB=m > > -CONFIG_USB_MON=y > +CONFIG_USB_MON=m > > -CONFIG_USB_OHCI_HCD=y > -CONFIG_USB_OHCI_HCD_PCI=y > +CONFIG_USB_OHCI_HCD=m > +CONFIG_USB_OHCI_HCD_PCI=m > -CONFIG_USB_UHCI_HCD=y > +CONFIG_USB_UHCI_HCD=m > > -CONFIG_RTC_I2C_AND_SPI=y > +CONFIG_RTC_I2C_AND_SPI=m > > -CONFIG_DMI_SYSFS=y > +CONFIG_DMI_SYSFS=m > > Some SCSI support can be more modularised as well What about all the VMs you keep going on about? The SCSI_VIRTIO driver is used by most modern linux virt platforms for storage and is a dependency. It could possibly be modularised but would slow boot down. > -CONFIG_BLK_DEV_SD=y > +CONFIG_BLK_DEV_SD=m > -CONFIG_CHR_DEV_SG=y > +CONFIG_CHR_DEV_SG=m > > 9) I think that this could be modularised as well I bet it actually can't be as I suspect it's probably used quite early in the boot process for some systems booting to get system information by other drivers. > -CONFIG_NVRAM=y > +CONFIG_NVRAM=m > > 10) Definitelly this can stay as module > -CONFIG_RAW_DRIVER=y > +CONFIG_RAW_DRIVER=m > > 11) Mentioned already ext support: Why, it's used by the vast majority of systems, makes things easier to debug and faster to boot, also allows to boot without a initrd in some cases. > -CONFIG_EXT4_FS=y > +CONFIG_EXT4_FS=m > -CONFIG_JBD2=y > +CONFIG_JBD2=m > > 12) Not everyone is using quota > -CONFIG_QUOTA_TREE=y > +CONFIG_QUOTA_TREE=m > > This is not probably all .. No, it's not, but it also doesn't take into account the reasons, some may be historical why things are the way they are, and it's mostly you're opinion which may or may not be close to reality. Ultimately a lot of things like EXT4, ATA, SCSI and other things being built in come down to boot speed, ease of support and debugging. Throwing this out to devel in one massive big suggestion isn't really helpful. If you want to get involved in the kernel by all means, the more the merrier but do some research first and find out why things are the way they are before wading in. In some cases I doubt you've even tested a kernel build to see if it works, I can see one option I know has other dependencies which would cause it to fail to even build! Peter _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
