From owner-freebsd-current  Sat Dec  7 23:42:12 1996
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id XAA00849
          for current-outgoing; Sat, 7 Dec 1996 23:42:12 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id XAA00844
          for <freebsd-current@freebsd.org>; Sat, 7 Dec 1996 23:42:10 -0800 (PST)
Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.8.4/8.6.9) with ESMTP id XAA00769; Sat, 7 Dec 1996 23:40:51 -0800 (PST)
To: Terry Lambert <terry@lambert.org>
cc: freebsd-current@freebsd.org
Subject: Re: cvs commit: src/include utmp.h 
In-reply-to: Your message of "Sat, 07 Dec 1996 12:43:16 MST."
             <199612071943.MAA27564@phaeton.artisoft.com> 
Date: Sat, 07 Dec 1996 23:40:50 -0800
Message-ID: <765.850030850@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> This is simply a matter of allowing someone to make the necessary
> changes to seperate the data from the procedures which operate against
> it, and seperating the procedures into logical units.

Sounds reasonable.  So let's talk prototypes. :-)

> At the lowest level, this means going to an rc.d mechanism for per
> logical unit start/stop/status and ordering.  You could support
> run levels at the same time, but it's not strictly necessary.

I'm not yet convinced that the time is fully passed for further
*incremental* improvements to the existing "flat" rc file structure,
some of the types of abstraction you're looking for being possible
with further extentions to the /etc/sysconfig concept, and without
taking the big political hit of arguing for something which smells too
much like SYSV for many people's tastes.

Please note: I'm not saying that a nested rc.d structure is a bad
idea, I frankly don't even care that strongly since I see it as a "six
of one, half a dozen of the other" kind of argument.  However, past
experience has (amply!) shown that anytime you start talking about
reorganizing the /etc files and even so much as hint at "rc.d/", you
might as well just kiss your proposal goodbye since it's only about to
be barbequed in the flame-fest which is sure to follow.

Let's start smaller and first separate knobs from labels in the
existing stuff, then see where people seem willing to go from there.

					Jordan