> 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.
I use those, though I'm unsure if it's a level of usage that you'd consider significant (I also use x32 to a similar extent :-).
I run a Munin master for 17 nodes on an f1-micro with
buster-backports cloud-amd64 - proxied via App Engine to get 1GB/day out for viewing graphs, rather than 1GB/month/region. Works well enough that I didn't immediately feel the need to pare it down to a bare minimum and roll my own like I do with the regular kernels. (I may try to e.g. avoid SMP overhead or cut fs features to increase inode/dentry slab density; but not sure I can compile it locally on a 20% of Skylake core with
1GB RAM, especially when it's already over half its available resources to generate/store graphs.)
My initrd (dep, xz) seems to have gone up from 4.66 MB on disk in
5.4.0-0.bpo.3-cloud-amd64 to 5.12 MB for bpo.4, but the kernel memory line suggests RAM was minimally impacted by 4KB.
As for the more general question: to me, a 'cloud' machine is just a VM offered via a cloud provider, supporting the management interfaces of such providers out of the box. It may be a relatively 'large' machine, hosting guests of its own. I wouldn't expect to see drivers for old directly-attached hardware, but legacy or research filesystems and protocols and drivers used for access to enterprise external storage seems reasonable, as cloud may be used to migrate older workloads or handle research projects. "Bare metal cloud" may be outside its remit - though, these will tend to be newer hardware.
Best regards,