On Wed, Oct 28, 2026 at 10:41:15AM -0400, Noah Meyerhans wrote: > On Wed, Oct 28, 2026 at 02:42:47PM +0100, Bastian Blank wrote: > > Since some time I wonder if it would be useful and possible to > > re-designate (and later rename) this kernel for "all" virtualized > > platforms. Most of them already work anyway, as they all expose similar > > hardware, not the same but similar. > > I agree with all of this.
Yep - we did this at $dayjob to avoid vendor-specific kernels and it's been good. > > We currently already include: > > - Complete non-root support for HyperV. > > - Complete non-root support for XEN. > > - Support for many of the devices exposed by qemu in both pc and q35 mode. > > > > What is known to be missing: > > - Support for VirtualBox. > > > > What else? The question is then also: should we then re-add support for > > stuff like GFS or so? Should we care about VMware's emulated physical fallbacks? IIRC their block layer emulates lsi logic, I think it uses mpt2. Should we care about more networking virtual function drivers? I know igbvf, iavf, idpf aren't currently included. I don't feel strongly - these are probably pretty specialized. > > Also in the near future, the second build will go away and we will only > > have a stripped down modules package left. So in the future we'll > > select by module, not longer by config. > > How granular do you plan on making the modules packages? Use cases for > things like filesystems and network protocols are likely going to be the > same across cloud and non-cloud deployments, so it might make sense to > have a "common" modules package that's installed by default in just > about all cases. I think a lot turns on whether there's a useful division of the modules into binary packages that *doesn't* create hundreds of them to juggle. > The major differences between virtualization platforms > is in the device models they expose to guests. Would it be feasible to > offer dedicated "aws", "hyperv/azure", "gcp", etc driver packages that > provide hardware support for those specific environments? Or is that > too much work/overhead? The benefit of such disk space optimizations > can be significant when scaled across hundreds or thousands of systems. There's also disagreement between the cloud vendors is when a driver should be =m vs =y. At work, I took the max of (n < m < y) since it's safer from breakage. But it might be nice to make more subtle decisions, to implement the platform-specific packages? > For the record, I don't love the idea of eliminating the second kernel > build. While we haven't taken advantage of this opportunity to this > point, it allows us to provide build-time optimizations to best tune > performance for specific deployment scenarios. But I suppose runtime > tuning is sufficient for most people, as we haven't received any > requests for different build-time optimizations afaik. So I don't > object too strongly to the plan, and I understand that it offers some > advantages. Are there specific optimizations you have in mind that would become impossible? Ross
