On 2021/08/25 10:35, Sebastien Marie wrote: > On Tue, Aug 24, 2021 at 01:53:41PM +0200, Paul de Weerd wrote: > > I have a new machine where I'd like to use IPMI. Of course, doing > > `config -e -f /bsd` will break KARL, so I tried to find a minimal way > > of supporting this. Done by introducing a new config file, > > /etc/kernel.conf, which gets applied to the kernel reorder_kernel > > builds and installs. > > I like it: it is simple. > > but here are some thoughts (with questions and some answers, but it is > open): > > - does it integrate well with syspatch ? > > yes, syspatch will call /usr/libexec/reorder_kernel (and the > configuration will be applied) > > > - after install or upgrade, does the installed kernel (by installer) > has the configuration applied ? > > it seems not: install.sub has it owns logic and is directly calling > "make newbsd ; make install" and do not use reorder_kernel script. > > > I could see reason to avoid it, and reason to requiring it. > > > For install, no problem: the file is controlled (it doesn't > exist). It doesn't change anything. > > For upgrade, the file could exists. Should the installer using it or > not ? > > > If using it, it makes the upgrade process dependent of the file: how > to deal with an invalid file ? should the file ignored (kernel > installed but not configured) ?
I don't see a reason why upgrade shouldn't use it. Invalid file handling is no more or less of a problem for upgrades than reboots. > how to deal with a format change in config(8) (file on disk in old > format, used config(8) understanding new format) ? but config(8) > doesn't change often, and could take care of both formats for one > release, and/or current.html could mention some required changes. > > > If not using it, does it is a problem that the first boot will be > different from next boot ? > > I could imagine some changes made to be the machine bootable, so the > first boot could lead to unbootable machine (but it isn't different > from now). > Questions are open: I have no problem which using or not using the > configuration file on upgrade, but I think it should be documented (to > avoid questions and/or surprises). > Somebody had an earlier method for applying kernel config changes automatically that IIRC used a bootloader based mechanism passing the config to the kernel. I think that might actually be better overall as you could bypass it at the boot loader (rather than requiring a backup "clean" kernel) though that's more work and I expect difficult to do within space constraints on some archs. I would be quite happy to have this problem solved one way or another, while a "one size fits all" kernel should be the goal, there are some workarounds needed e.g. for semi-broken hardware and I think that's always likely to be the case.
