On Thu, Sep 01, 2022 at 10:37:03AM -0400, Prarit Bhargava wrote: > Hey Gerd, > > Thanks for this changeset. > > On 8/31/22 08:46, Gerd Hoffmann wrote: > > Hi, > > > > Here is a little patch series to kick off a discussion on pre-generated > > initrd images and unified kernels. Lets start with a description of the > > patches: > > > > Patch #1 adds a dracut config file, targeting virtual machines. Given > > that most physical machines have either sata or nvme disks these days > > it probably boots most physical systems too. > > No critical objections from me, however, just a few long-term questions > about this approach. > > How are you going to prevent feature-creep in the initrd? What happens when > someone asks us to include "driver X" in this general initrd? How do we > determine whether or "driver X" is or is not appropriate for inclusion? If we limit the targetted usage to only be VMs, then we limit the scope of drivers significantly, since there's a small finite set of hypervisor we care about providing disk images for (VMware, HyperV, Xen, KVM), and thus we know what drivers are needed in order to be able to get out of the initrd into the root fs. If we extend to usage in bare metal scope of drivers becomes a little more open ended potentially, and I don't have a definite answer for what the criteria would be in that case. Worth noting though that systemd has a extension mechanism https://www.freedesktop.org/software/systemd/man/systemd-sysext.html that can be used to augment the pre-built initrd with further content. Fedora could ship certain drivers are separate extension images, or users could build their own extension images (though they would need to deal with their own SecureBoot keys in the latter case). > > Patch #2 adds a sub-package with an initrd image. > > > > Patch #3 adds a sub-package with an unified kernel. > > These will be built all the time. I'm worried about storage, etc., when > adding new sub-packages. Having said that, I do really like the idea ;) and > would definitely argue that it is worth it. For reference, in the kernel-virt-unified sub-RPM that my patches build, I'm created two EFI images, each of which is 40 MB in size, so total of 80 MB size for that new sub-RPM. When -debug builds are enabled, you get the same again for kernel-debug-virt-unified, so 160 MB total. THe overall kernel build output for x86_64 is 2.1 GB though, largely thanks to the enourmous -debuginfo packages, which dwarfs the extra 160 MB for these EFI images. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
