Proposal: disaggregated kernel parameters for Linux

[Simon Rowe]

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.

 

Regards
Simon