On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys red@fedoraproject.org wrote:
Heads-up: I've taken ownership over the Cloud SIG's planned "Cloud-Friendly Kernel Packaging" (aka "Modular Kernel Packaging for Cloud") Change [0].
(Sorry for cross-posting this on the kernel and cloud lists, but both the kernel team and the cloud SIG need to be involved in this discussion).
Obviously, we wish for modular kernel packaging and Josh Boyer already reached out to the cloud SIG in this regard a while ago when we didn't really know what we want yet [1]. We do now know that somewhat better [2] but details could still require additional discussion. Our motivation is to save space, time and bandwidth (the latter two referring to required updates) as in the cloud, all three equal to costs. And yes, we also target things other than the kernel to save space.
So, in our case hardware drivers are rather unnecessary and the kernel experts might know other ways to shrink the footprint for our limited use cases. The kernel we require supports all primary architectures (i686 and x86_64 right now, ARM likely later) and is able to run on a hypervisor (primarily KVM and Xen but support for ESXi and Hyper-V are becoming crucial in private clouds). Only. No bare-metal. We also require support for Linux Containers (LXC) to enable the use of Docker.
Now, I heard some people screaming when I said HW drivers are unnecessary. Some people will want to make use of PCI passthrough and while I think we don't want to ship the necessary modules by default, they should be easily installable through a separate package. If some more granularity is acceptable (and makes sense), I think one package for SRIOV NICs, one for graphic cards (to enable mathematical computation stuff) and one for everything else PCI passthrough (plus one for all other HW drivers for the non-cloud products) would be totally nice.
What does everybody think about this? Can it be done? How is it best done? What's the timeframe (we'd really like to see this implemented in F21 Beta but obviously the earlier modular kernels can be tested, the better)? Do you require additional input?
Please try to keep the discussion as simple as possible (in terms of us non-kernel hackers should be able to follow it). Just like Josh requested when reaching out to us: "Explain it to me like I'm a child."
Some drivers are built inside the kernel (for various reasons) so if we keep them in they can't really be modular. If we are going down this route (ex. kernel-hw-drivers sub package) we should have a way to handle upgrades. You don't want to upgrade and be left out without any hardware support because it is now a sub package that nothing pulls in.
How much are you trying to save by this? All modules (excluding extra which is already a sub package) are ~115MB here on x86_64.