Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #82593
| 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 |
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
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