Portal:Jump/Kernel
This is a page to map current plans with kernel in future openSUSE Leap based on the Jump proposal.
Option 1
Three flavors, where kernel-preempt represents kernel as it is in openSUSE Leap 15.2
- kernel-rt
- kernel-default
- kernel-preempt
Option 2
- kernel-rt
- kernel-default (use just SLE kernel)
Option 3
Questions
kernel-default-extra
What's going to happen with kernel-default-extra? We use it in SLE-WE and SLED to provide some unsupported drivers that are useful in desktop environments. Current Leap ships all these drivers anyway, in the normal kernel-default package. If this is unified, we need a different approach for SLE-WE / SLED. Install size may matter here, too.
Unsupported modules
The SLE kernel has the CONFIG_SUSE_KERNEL_SUPPORTED feature enabled. This sets kernel taint flags if kernel modules are loaded that have no official support from SUSE or its partners. The purpose is in case of issues, customers are able to prove that they are running a supported kernel configuration. Under openSUSE, the support status has no significance and should ideally be completely hidden from users, to avoid confusion. At least, Leap users shouldn't end up with crippled systems because of modules not being loaded due to missing "supported" flags.
Kernel flavor naming
- kernel-preempt already exists in SLE as experimental package (not released to customers). That still makes Option 1 conflict with existing packages
- kernel flavor name cannot contain a dash
Leap kernel features
- Currently it is accepted that Leap kernel may include features that are not suitable for SLE. Some are modules that could be packed into kernel-default-extra but others are choices that need to be set at build time and result in a different, incompatible kernel binary. Option 2 will cause a regression in Leap kernel features and infringe on ability to accept features to Leap kernel.