Hey Andrew, On 2024-05-22 07:44, Andrew Jorgensen wrote: > 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.
In general the procedure to get a new module enabled in a future Debian release is: - open a bug report just like you have done for I6300ESB_WDT [1] - open a corresponding merge request on Salsa, Vincent did that for I6300ESB_WDT already [2] Which files to edit and how to build a kernel with the module(s) on may not be immediately obvious. As I was learning how to do it myself, I posted some notes on [3]. Perhaps we could add a section to the Debian Kernel Handbook now that I think of it. The final step is waiting for someone to review and merge your changes, with a gentle ping on irc (#debian-kernel on oftc) in case nothing happens for a while. :-) Perhaps someone else may comment for backports, I imagine the steps to follow may be similar but don't know for sure. > 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. Emanuele [1] https://bugs.debian.org/1067908 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1059 [3] https://www.linux.it/~ema/posts/enabling-kernel-settings-in-debian/