Modular Kernel Packaging for Cloud

[Don Zickus]

On Wed, Mar 05, 2014 at 08:25:12PM +0900, Sandro "red" Mathys wrote:
> > 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
> tested.
> 
> > 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. :)

I disagree with that approach.  'Every MB counts' is a difficult concept
to implement and forces folks (like the kernel) to implement radical
changes to achieve some 'pie in the sky' requirement that you are never
really sure you have achieved.

How about something more sensible, hard limits.  Go through your package
requirements and allocate a chunk of space to everyone and see how that
works (well not to each userspace package individually but collectively).
If that is too big trim some places.

For example, lets start with 100MB package requirement for the kernel (and
say 2 GB for userspace).  This way the kernel team can implement
reasonable changes and monitor proper usage (because things grow over
time).

If later on you realize 100 MB is not competitive enough, come back and
chop it down to say 50 MB and let the kernel team figure it out.

But please do not come in here with a 'every MB counts' approach.  It is
not very sustainable for future growth nor really easy to implement from
an engineering approach.

Is that acceptable?  The kernel team can start with a hard limit of 100MB
package requirement (or something reasonably less)?  Let's work off budget
requirements please.

Cheers,
Don