Jason Thorpe <[email protected]> writes: > 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)
> 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. That seems sound. > 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). That is a rule in NetBSD but I do not expect it is followed by all scripts installed by pkgsrc. A different view is that the basic rule is that an rc.d script must implement start, stop, status, reload, and should check a variable. rc.subr is certainly a good library to use, and a convention, but it isn't strictly necessary. > 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. Sure, but we can say that "invoked with a command that isn't understood" should lead to quick error exit as an implied specification, far more strongly than we can say that using rc.subr is an implied specification. There are a lot of packages with scripts and many of them are old. > 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”. I don't see any downside to inverting the test. >> (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. I said "at first". While every change that's committed is believed to not cause regressions, it seems best to let the first 20 people opt in and after it's been a month or so and there are no bugs on the table, it seems ok to make it default. Basically I don't think it's ok to push testing onto current-users, until there's been enough testing that finding a bug would be very surprising. In this case, testing is all about environments you haven't contemplated.
