On Mon, Jun 2, 2025 at 10:14 AM Kyle Evans <kev...@freebsd.org> wrote: > > On 6/2/25 00:49, Simon J. Gerraty wrote: > > The branch main has been updated by sjg: > > > > URL: > > https://cgit.FreeBSD.org/src/commit/?id=61d77e6c009544d1489078c16a5d22b27d25c91b > > > > commit 61d77e6c009544d1489078c16a5d22b27d25c91b > > Author: Simon J. Gerraty <s...@freebsd.org> > > AuthorDate: 2025-06-02 05:48:43 +0000 > > Commit: Simon J. Gerraty <s...@freebsd.org> > > CommitDate: 2025-06-02 05:48:43 +0000 > > > > loader: allow for exceptions to restricted settings. > > > > We restrict what an unverified loader.conf etc can set, > > and the same restrictions are applied to interactive input. > > We need to allow for exceptions (eg boot_verbose). > > It is best if any allowed settings match up to '='. > > > > If we do not allow it to be set, do not allow it to be unset > > > > Reviewed by: stevek > > Sponsored by: Juniper Networks, Inc. > > --- > Long-term, we should probably work out something that can work for > lualoader, too. We use setenv() there directly rather than adding a > layer of indirection through the command-line parser.
Yea, I'd rather this be a property of the env variable than having lists like this anyway. And that would solve another problem I have from time to time which is needing to have an always existing env variable with a default, but overridable value. In these cases, you have to set that up in code, and it's a bit of a bother. If we do it right, we could have a three-fer: works with lua, works to set certain things immutable after a time and also lets us initialize things. Though getting the details right so that we can set these in loader.conf, but then not set them on the command line is the most likely use case, and I thought for that use case we did the right thing in lualoader. no? Warner
