On Thu, Sep 1, 2022 at 9:58 AM Daniel P. Berrangé <berrange(a)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