Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Noah Meyerhans Newsgroups: linux.debian.kernel Subject: Re: Kernel features and Cloud (and GCE) Date: Mon, 27 May 2024 17:50:01 +0200 Message-ID: References: X-Original-To: Emanuele Rocca X-Mailbox-Line: From debian-kernel-request@lists.debian.org Mon May 27 15:49:47 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.1 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=1, LDO_WHITELIST=-5] autolearn=unavailable autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/142793 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/ZlSrfbXTM18YoJV1@doom.morgul.net Approved: robomod@news.nic.it Lines: 26 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Andrew Jorgensen , debian-kernel@lists.debian.org, debian-cloud@lists.debian.org, Zach Marano X-Original-Date: Mon, 27 May 2024 08:49:17 -0700 X-Original-Message-ID: X-Original-References: Xref: csiph.com linux.debian.kernel:82592 On Mon, May 27, 2024 at 03:37:08PM +0200, Emanuele Rocca wrote: > > 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. > > I think the best approach is enabling the needed modules one by one in > the cloud image following the procedure above. Andrew's question is a bit higher level than that, and mostly boils down to "Which cloud environments do we actually want to support with the cloud kernel?" We have declined requests to enable modules in the cloud kernel in the past, referring people to the standard kernel instead (see e.g. #969140). See also the previous discussion at #https://lists.debian.org/debian-kernel/2020/04/msg00006.html We have not, as far as I can recall, ever explicitly stated a policy around this, nor have we documented what it would take for us to support more fine-grained kernel builds (i.e. what stops us from generating a kernel image targeting *only* GCP). noah