At 6:36 PM +0100 2/1/02, Erik Trulsson wrote:
>Consider that the actual code in the various rc* start scripts is
>in most cases of the form:
>if foo_enable==yes
>   do stuff
>   do nothing

Let me approach this from a different angle.  Several people have
tried to argue this by proposing various "What if?" scenarios.
Let me also do that.

Let us say that we did happen to decide that for all 'foo_enable'
options in rc.conf, a setting of 'foo_enable=no' does in fact
mean that the service 'foo' will NOT be running at the end of
the boot-up process.  Maybe some company offers us a million
dollars if we will just guarantee that, and we think of all the
good programmers we could pay for that million dollars, so we
all agree to standardize on this definition of 'enable=no'

If we decided to do that, then as a *practical* matter, how many
of the current options in rc.conf would need to be changed?  I
don't mean "if we need to cover the case where someone renames
/usr/sbin/lpd to /bin/echo, what would we need to do?".  I mean,
given any default installation of the base operating system (no
ports), and any valid kernel configuration, in what cases of
'enable' would we really *have* to add some lines to those 'else'
clauses that you quoted?

In the case of lpd_enable, as a *practical* matter, there would be
no need to write additional code.  There is no kernel setting which
automatically turns on lpd support, and if 'lpd_enable=yes' does
not *start* /usr/sbin/lpd, then we do know that the lpd program is
not running.

I don't have time to look into it now, but I expect that is true for
all of the other 'enable' options.  As a *practical* reality, I expect
that the firewall_enable option is the only one where we do need to
write code to implement the 'enable=no' case as I described it.

People will argue that "this is special, because it's a kernel option!
Lpd would behave exactly the same way, *if* it were a kernel option!".
All fine and good, *if* it were true, but irrelevant to my "What if?"
question.  Of the current foo_enable options, which options would we
need to change *right now* to support the definition of 'enable=no'
that some people think is logical?

[mind you, I don't actually know the answer to that question, but I
just got a phone call and need to leave right now...  So, I am
breaking the first rule of a good lawyer, in that I am asking a
question that I don't already know the answer to.  :-)   ]

Garance Alistair Drosehn            =   [EMAIL PROTECTED]
Senior Systems Programmer           or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute    or  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to