Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.kernel > #82593

Re: Kernel features and Cloud (and GCE)

From Bastian Blank <waldi@debian.org>
Newsgroups linux.debian.kernel
Subject Re: Kernel features and Cloud (and GCE)
Date 2024-05-27 21:10 +0200
Message-ID <IINTj-gfsU-11@gated-at.bofh.it> (permalink)
References <IGVLk-f5BP-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hi Andrew

On Wed, May 22, 2024 at 07:44:33AM -0700, Andrew Jorgensen wrote:
> The Debian images in Google Compute Engine use the Debian cloud
> kernel. This has been working well for us, because it includes the
> VirtIO, NVMe, and gVNIC drivers that are needed for most GCE machine
> types. As we move forward, additional kernel features are needed to
> support all features of current and future machine types.
> 
> For example, we’re going to make an Intel 6300ESB watchdog device
> available, and that needs a driver that’s been in Linux a long time
> but isn’t enabled in the cloud kernel. For that one, another Debian
> user +1’d the request because it would benefit users of other
> KVM-based clouds (including private clouds). We can enumerate other
> examples, but many of those also require backports or a future Debian
> release.

We already backport the Microsoft MANA network driver.  So at least
backports to stable are not that of a problem, if someone does it.
Backports to oldstable are most likely not happening, as this target is
too far off.

> Recently in response to another feature request for the cloud kernel,
> Noah Meyerhans mentioned that, “historically the cloud kernels have
> specifically targeted Amazon EC2 and Microsoft Azure.”

Yes, this is the documented target.  We did never properly add GCP,
because no communication happened.  I think we can do that, if someone
does a due diligence and knows the documentation better then we.

> So we have the problem that the Debian cloud kernel supports some, but
> not all, of the devices our shared users need, and we’re not sure of
> the right way to solve that. We wondered if we should switch the
> images to the generic kernel, or if there’s a way we could help the
> cloud kernel support more clouds, or if there’s a better solution we
> haven’t thought of.

We can support more clouds.  It is just a matter of taking care of it.

I currently play with splitting the modules into multiple different
sets, like almost all other distributions already do.  We would not need
to do multiple builds then and more targeted packages would be possible
if needed.

Regards,
Bastian

-- 
Conquest is easy. Control is not.
		-- Kirk, "Mirror, Mirror", stardate unknown

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Kernel features and Cloud (and GCE) Andrew Jorgensen <ajorgens@google.com> - 2024-05-22 17:10 +0200
  Re: Kernel features and Cloud (and GCE) Emanuele Rocca <ema@debian.org> - 2024-05-27 15:40 +0200
    Re: Kernel features and Cloud (and GCE) Noah Meyerhans <noahm@debian.org> - 2024-05-27 17:50 +0200
  Re: Kernel features and Cloud (and GCE) Bastian Blank <waldi@debian.org> - 2024-05-27 21:10 +0200
  Re: Kernel features and Cloud (and GCE) Marco d'Itri <md@Linux.IT> - 2024-05-28 17:20 +0200
    Re: Kernel features and Cloud (and GCE) Andrew Jorgensen <ajorgens@google.com> - 2024-05-29 18:20 +0200

csiph-web