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