From owner-freebsd-hackers Sun Apr 27 14:24:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA29618 for hackers-outgoing; Sun, 27 Apr 1997 14:24:46 -0700 (PDT) Received: from cold.org (cold.org [206.81.134.103]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA29612 for ; Sun, 27 Apr 1997 14:24:41 -0700 (PDT) Received: from localhost (brandon@localhost) by cold.org (8.8.5/8.8.3) with SMTP id PAA09661; Sun, 27 Apr 1997 15:23:46 -0600 (MDT) Date: Sun, 27 Apr 1997 15:23:46 -0600 (MDT) From: Brandon Gillespie To: Terry Lambert cc: jkh@time.cdrom.com, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. In-Reply-To: <199704271932.MAA09051@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Note.. With the comparisons to Solaris using rc.d and init.d I'd like to point out that Digital Unix has also moved to this form of initialization (versus Ultrix). It does have its drawbacks, and its goodies... On Sun, 27 Apr 1997, Terry Lambert wrote: > > I think it is more a case of functionality, rather than personal > > preference. With the rc.d/init.d approach you have more modularity, > > and the ability to start/stop random packages in a consistent way. > > There is also a single standard place that a vendor can throw a > > startup script in--this is a good thing. > > Yes. The modularity and the provision for vendor startup scripts > (which already exist for many IBCS2/SVR4/Solaris commercial software > distributions) are my main reason for supporting the model. It is > an IBCS2/interface compliance issue. > > That you can start and stop components is a bonus, as is the ability > to support multiple running confiurations for a laptop that may be > disconnected from the net, intermittently IR/Wavelan/etc. connected, > modem/cellular-modem connected, and/or docked. Each is a different > run state (*not* run level). > > > What does the rc?.d buy us again? And the two-digit prefix? These > > are no more than a hack aimed at solving the dependancy problem--and > > they only solve the ordering part too. I think multiple > > configurations could be better served than dirs full of symlinks as > > well. > > Yes. This is a kludge that has to do with implementation of *levels* > rather than implementation of *states*. I think the numeric designators > are somewhat flawed. I would like to see "rc.xxx" directories, where > "xxx" is the name of a state. I'd also like to see the ability to > transition states based on PnP events ("Hey! I'm docked! Start the > directly connected network!"). I definitely agree, I abhore the rc?.d stuff--I can never remember what is what (especially since it has some variance depending upon the O/S). What would work, assuming FreeBSD moved to something like this, would be to have rc.STATE and simply symlink rc[013].d to the appropriate states, to keep the familiarity. Altho, I would debate the [SK][0-9][0-9]NAME syntax (where 'S' or 'K' is called depending upon if its a startup or shutdown action of that level) If we did it as a state you could have seperate states for startup and shutdown, which would alleviate the need for crufty 'S' and 'K' prefixes. I'd personally also like to see a dot seperater supported as a convention. This is, of course, completely preferencial, but: 20.ntp 25.ftp 60.inetd 70.local Is much 'better' (imho) than: S20ntp S25ftp S60inetd S70local -Brandon Gillespie