Modular Kernel Packaging for Cloud

[drago01]

On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys
<red at 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.