Josh, thanks to reaching out to us on this. It's good to know the
kernel maintainers are willing to discuss this openly.
On Wed, Oct 30, 2013 at 3:07 PM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
I realize the WG is just forming up and you have a lot of other items
to cover for now, but I wanted to get this sent out and have people
start thinking about it sooner rather than later.
The kernel team has heard in the past that the Cloud group would like
to see something of a more minimal kernel for usage in cloud images.
We'd like to hear the requirements for what this smaller image would
need to cover.
Right now, a default x86_64 kernel package on f20 is ~134MB installed.
Most of that is device drivers installed in /lib/modules/`uname -r`/.
The vmlinux binary is about 5MB and the initramfs (which is created
at install time and can actually vary quite widely depending on
various things) is about 11MB. Drivers can be trimmed to a degree,
but please keep in mind that the kernel is already relatively small
for the functionality it provides. For example, it is not much bigger
than glibc-common (119MB).
So, some caveats to keep in mind while you're thinking about this:
1) We're mostly talking about packaging here, not building a separate
cloud kernel package or vmlinux. The kernel team really wants to have
a single vmlinux across the 3 products if at all possible. We can't
scale to much else.
2) What usecases is the cloud image going to cover? E.g. is it just
virtio stuff, or will it also fit PCI passthru (which then requires
drivers for those PCI devices)?
3) What are the common provisioning requirements that are driving the
size reduction? (See comment about glibc-common. I would think
change is needed in multiple packages, not just the kernel.)
4) Other "cloudy" stuff that I'm entirely unaware of that might be
relevant. Explain it to me like I'm a child.
So I think it really comes down to two decisions we've yet to make:
1) Which environments (hypervisors both with and without
pci-passthrough, containers or bare metal - all three do have valid
cloud use cases nowadays) do we want to support and how many different
images do we want to create (i.e. one to rule them all or one per
environment - or even more granular). The one-to-rule them all will
quite certainly require a full Fedora kernel as-is. Well, maybe
without stuff that's rather exclusive to workstations but that also
goes for the Fedora Server Product, right? The others might leave away
some parts (like all real HW in a strictly-for-hypervisors
without-pci-passthrough image), depending on how granular we go.
2) Another topic is really that of allowing the user to rebuild our
images with slightly(?) different options for a slightly(?) different
use case. If we do want to enable users to do that, we might wish to
also enable to user to be more granular than we are.
Now, I primarily wonder, how are those 134MB distributed? My
filesystem tells me e.g. the net or the media drivers are a large
chunk but that doesn't help much. Can't really estimate what parts of
that are always necessary, whart are virt HW and what other HW.
Anyway, I doubt it makes sense to e.g. remove pcmcia drivers because
we don't use them as they are very very small. So I think it would be
nice to have:
- kernel-virt-hw (all that is found in any of the common hypervisors)
- kernel-real-server-hw (any non-virt HW that is not exclusive to workstations)
- kernel-real-workstation-hw (any non-virt HW that is exclusive to workstations)
- kernel (well, the common / small stuff)
If you're now going to tell me the kernel-virt-hw package would still
be rather large, I'd further split that one into smaller sub-packages
(e.g. virtio, xen-guest, pci-passthrough, ...)
Not sure if that's possible at all and if so, how useful it is. I
don't understand the kernel internals at all, just trying to show you
my cloudy dreams. Hopefully, I did not only talk nonsense. :)