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 :|