On Thu, Sep 1, 2022 at 9:58 AM Daniel P. Berrangé <berra...@redhat.com> wrote: > > 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).
There are some other options here for longer term, ways to hopefully make this easier to deal with. I like the concept of this, and it is rather surprising just how many "kernel bugs" end up being badly generated initramfs on a local machine, which this can also help alleviate. I need to think it through a bit, but my initial reaction is that the advantages outweigh the disadvantages. > > > > 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. The debuginfo rpms are not passed around nearly as much in many contexts, so it is a significant change. I am not saying it is not worthwhile, just saying the size difference does need to be kept in context (how many people mirror repos, but not debuginfo?) Justin _______________________________________________ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
