For buster, we generate a cloud kernel for amd64. For sid/bullseye,
we'll also support a cloud kernel for arm64. At the moment, the cloud
kernel is the only used in the images we generate for Microsoft Azure
and Amazon EC2. It's used in the GCE images we generate as well, but
I'm not sure anybody actually uses those. We generate two OpenStack
images, one that uses the cloud kernel and another uses the generic
kernel.
There are open bugs against the cloud kernel requesting that
configuration options be turned on there. [1][2][3] These, IMO,
highlight a need for some documentation around what is in scope for the
cloud kernel, and what is not. This will help us answer requests such
as these more consistently, and it will also help our users better
understand whether they can expect the cloud kernel to meet their needs
or not.
At the moment, the primary optimization applied to the cloud kernel
focuses on disk space consumed. We disable compilation of drivers that
we feel are unlikely to ever appear in a cloud environment. By doing
so, we reduce the installed size of the kernel package by roughly 70%.
There are other optimization we may apply (see [4] for examples), but we
don't yet.
Should we simply say "yes" to any request to add functionality to the
cloud kernel? None of the drivers will add *that* much to the size of
the image, and if people are asking for them, then they've obviously got
a use case for them. Or is this a slipperly slope that diminishes the
value of the cloud kernel? I can see both sides of the argument, so I'd
like to hear what others have to say.
If we're not going to say "yes" to all requests, what criteria should we
use to determine whether or not to enable a feature? It's rather not
leave it as a judgement call.
noah
1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952108
2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955366
3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955232
4. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947759