Modular Kernel Packaging for Cloud

Sandro "red" Mathys red at
Wed Mar 5 11:25:12 UTC 2014

On Wed, Mar 5, 2014 at 6:58 PM, drago01 <drago01 at> wrote:
> On Wed, Mar 5, 2014 at 8:48 AM, Sandro "red" Mathys
> <red at> 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 there are reasons they are built-in (and I think currently nothing
is being built-in without good reasons), that should not be changed.
Only just talking about what is currently a module (or otherwise a
separate file - if applicable). The vmlinuz should be kept as-is and
stay the same for all products (server, workstation and cloud).

> 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.

Yes, that's only too true. But it should be possible to guarantee
proper upgrades through means of packaging. And of course this will be

> 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.

As much as is sensibly possible. Every MB counts but we don't want to
drive the kernel team members insane. :)

-- Sandro

More information about the cloud mailing list