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@xxxxxxxxxxxxxxxxx> wrote: > Hi All, > > 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. :) -- Sandro _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
