From owner-freebsd-current Fri Feb 1 14:12:12 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id B77FB37B404; Fri, 1 Feb 2002 14:12:06 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id g11MC0S61080; Fri, 1 Feb 2002 17:12:00 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020201173641.GA48397@student.uu.se> References: <15448.64681.401219.163184@guru.mired.org> <5F46C986-16DB-11D6-8CEC-00039359034A@mac.com> <20020201173641.GA48397@student.uu.se> Date: Fri, 1 Feb 2002 17:11:59 -0500 To: Erik Trulsson , Paul Fardy From: Garance A Drosihn Subject: Re: *_enable="YES" behavior is bogus Cc: current@FreeBSD.ORG, stable@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 >else > 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 = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message