> On Aug 18, 2026, at 3:41 AM, Greg Troxel <[email protected]> wrote: > > Can you explain the essence of how the code evaluates "script does > useful work"?
There’s a comment in the code that describies it: +# doeswork Returns 0 if the script does work that's needed +# for boot, non-zero otherwise. Scripts are considered +# to do work if either their rcvar is set to YES or +# if they do not have a defined rcvar. +# So let me explain the reasoning. If a script defines a controlling rcvar, then that script, by definition, has been requested to do nothing if the rcvar evaluates to NO. Scripts that do not define an rcvar fall into three categories: - scripts that always do some sort of work (e.g. mountcritlocal) - scripts that make some other determination as to whether or not they should do work (e.g. ccd) - the barrier scripts (e.g. LOGIN) The barrier scripts are needed only for ordering, and the dismissal of non-useful scripts occurs after ordering, but in my implementation they remain in the rcorder.cache bcause: (a) there’s not really a fast or simple way to distinguish them from the second category, and (2) given the number of truly non-useful scripts that typically get elided, having a couple in there that serve to document the sequencing points seems like a good trade-off. > The obvious way to put it is "is the effect on the system (other than > cpu time, filesystem reads, effects on caches) from running this script > the same as the effect of not running it"? I guess I can really distill it down to: “A script is considered to do no useful work only if it definitively tells us so.” And it does so by self-reporting that its rcvar is set to NO. > If there is a rule that each script must have a yes/no variable > controlling actions, then I can see this optimization. Or really, > skipping any script that does have a variable. But, rc.d scripts sort > of seem like arbitrary shell commands. I therefore wonder if we have > rules for rc.d scripts that enable this kind of optimization, or if some > subset of optimizable rc.d scripts are recognized. The basic rule for rc.d scripts that work in our system is “use rc.subr”. Any script that does will get a safe default for “does useful work”. Any script that doesn’t probably doesn’t actually work properly as it is today. A main design feture of our rc.d system is that scripts that don’t provide an explcit action for one of the directives get a widely-cast net of reasonable default behavior (and yes, I went back and read Luke’s USENIX paper again to provide maximum insurance against violating any religious tenents while working on this problem). > How does this interact with rc.d scripts from pkgsrc or elsewhere, that > do not necessarily follow rules? Well, the most important program in pkgsrc that supplies rc.d scripts (sysutils/nabud, of course) definitely follows the rules. A cursory audit of main NetBSD workhorse machine has a few pkgsrc-installed rc.d scripts, and they all DTRT as well. The one situation where it could fall over is “some random rc.d script doesn’t use rc.subr at all”, and this it will not respond to the “doeswork” directive. But even if I invert the sense to a “canskip” directive, some random rc.d script that doesn’t use rc.subr at all could choose to play Towers of Hanoi rather than exit with an error status. I guess my point is the only rule a script has to follow is “use rc.subr”, which seems to be an *incredibly* low bar (because if they don’t, there’s already a myriad of ways those scripts could fall over). If it follows that one rule, then the only way it gets optimized out is if is uses a control variable and that control variable contains the value that explcitiy says “yo script, you are to do no work”. > (Also, it seems obvious that if you commit this, it should default to > off at first, except perhaps for particularly slow arches.) Of course, this has the side-effect of reducing the amount of dog food-induced problem finding and is yet another step that people have to do in order to make their systems run fast, but ok, sure. -- thorpej
