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