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
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
