Re: Proposal: disaggregated kernel parameters for Linux

[Daniel Kiper]

Hi,

On Fri, Feb 02, 2024 at 09:58:06AM +0000, Simon Rowe wrote:
> I have a suggestion I’d like to have feedback on regarding the management of
> Linux kernel parameters.
>  
> Today the parameters for a Linux menu entry have to be specified in the
> GRUB_CMDLINE_LINUX entry of /etc/default/grub. These parameters cover a number
> of purposes, not just the kernel (e.g. initrd, systemd etc). Changes need to 
> be
> made for a variety of reasons and at different times, defining a new parameter
> (or changing an existing one) requires this single line to be updated. Doing 
> so
> is awkward, to be idempotent you first have to check if the parameter is
> present, then you have to find the appropriate insertion point (some 
> parameters
> are sensitive to ordering).
>  
> Many userspace subsystems today use a collection of dropin files in one or 
> more
> directories which are then read in a well-defined order to create a final
> configuration definition. This has a number of advantages:
>  
>     * parameters can be grouped logically together
>     * parameters can be packaged with their appropriate component
>     * parameters can modified simply by updating a file (which can be done
> atomically)
>     * ordering can be indicated by the name of the file (usually with a two
> digit number prefix)
>     * distinction can be made between distro defaults and values an
> administrator has chosen as overrides
>  
> This concept could be used by GRUB to build up the Linux kernel parameters
> dynamically when the config is generated.
>  
> Here’s an example:
>  
> The installer deploys the file /usr/lib/kernel.d/50-console.conf
>  
>      console=tty0
>  
> as a distro default. An admin can choose to deploy /etc/kernel.d/55-serial-
> console.conf with
>  
>     console=ttyS1,115200
>  
> to add a serial console that’s the default instead.
>  
> An example of replacement (rather than extension), the kdump package could
> install the file /usr/lib/kernel.d/10-crashdump.conf
>  
>     crashkernel=auto
>  
> but the admin finds he needs more specific settings so he creates /etc/
> kernel.d/10-crashdump.conf with
>  
>     crashkernel=32G-96G:128M,96G-:256M
>  
> in this scenario the file within /etc/kernel.d/ entirely replaces the file of
> the same name in /usr/lib/kernel.d/.
>  
> Files could also contain comments to explain their purpose.
>  
> Of course this could also be utilized by other bootloaders (and would 
> therefore
> make management of parameters consistent across different platforms).
>  
> I have a proof of concept for a specific usecase. If there’s interest in this
> approach I can transform this into something more generic and send out a set 
> of
> patches.

Looks interesting. Though I think this could also be applied to other
kernels/Xen/... Did you think how this could interact with the Boot
Loader Specification (BLS) [1] too? It is not yet implemented in the
GRUB but I hope we will get it in the following months...

Daniel

[1] https://uapi-group.org/specifications/specs/boot_loader_specification/