On Tue, Nov 30, 2021 at 10:11:36AM +0000, Stephen Borrill wrote: > In our products, we have a standard rc.conf and then a series of build > scripts that configure and enable/disable services as required. We can > switch between npf and ipfilter with a one-line change in a settings file, > for example. We heavily rely on rc.conf.d functionality for this. We may put > flags in there too. You could achive that too by including "local" files from your generic /etc/rc.conf (like: ". /etc/conf/firewall", maybe even guarded by tests for existance). > I don't think putting name=YES into /etc/rc.conf.d/name is wrong or working > by luck in general even if it is working by implication. If we want to support that, we should document it and have tests for it. Currently I would not guess this could work after reading the manual, and would not think about such usage when extending/modifying anything in /etc/rc*. > I think the "load_rc_config_var npf npf" line I've proposed in npf_boot is a > neat solution (and similar for pf_boot). It basically says get the value of > npf from wherever you may find it. It also avoids potential contamination of > the environment compared to my original fix. Yes, and I am not objecting that detail. > The split of /etc/rc.d/npf into two stages is analogous to swap1 and swap2. > In that case, those scripts explicitly load_rc_config swap and do not take > name into account. We should ammend the documentation Robert cited to say something like "in general $name, but in exceptional cases a well known service name is used instead (like: swap, npf, ...)". Martin