From owner-freebsd-current  Fri Feb  9 05:12:32 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id FAA28325
          for current-outgoing; Fri, 9 Feb 1996 05:12:32 -0800 (PST)
Received: from time.cdrom.com (time.cdrom.com [192.216.222.226])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA28310
          for <current@freebsd.org>; Fri, 9 Feb 1996 05:12:30 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id FAA19890; Fri, 9 Feb 1996 05:11:49 -0800
To: Julian Elischer <julian@ref.tfs.com>
cc: terry@lambert.org (Terry Lambert), current@freebsd.org
Subject: Re: FS PATCHES: THE NEXT GENERATION 
In-reply-to: Your message of "Tue, 06 Feb 1996 13:59:24 PST."
             <199602062159.NAA01076@ref.tfs.com> 
Date: Fri, 09 Feb 1996 05:11:49 -0800
Message-ID: <19888.823871509@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@freebsd.org
Precedence: bulk

> hmm but devfs might be compulsory :)

Erm..  I know you're probably joking, but since you bring it up.  I
don't think that we should even ever consider making devfs mandatory
(optional is fine, I don't mind optional) until a persistance
mechanism that's fully transparent to the user is implemented.

I had UNIX old-timers walk up and tear *my* ears off over this after
Julian's talk at USENIX - they were not at all pleased by his answer
that he considered persistance "a user problem" :-) However, their
impassioned diatribes did give me a chance to consider the matter of
persistence more fully myself, I have to say that I find myself more
or less in full agreement with them.

It has to work the way it works now, e.g. you should be able to just
walk into /dev (and that could be one of many incarnations of `dev',
remember) and futz with permissions or "delete" device entries you
don't want to be present for security reasons, and that information
should stay there across mounts.  David, Justin, Sean and I stood
around for awhile thinking of some ways this might be done in a log
file somewhere, and I'm sure the problem isn't insurmountable.  To NOT
do this and force our users to have to specifically edit chmod, mknods
or rm commands into /etc/rc in order to preserve their changes to /dev
across reboots, well, the phrase "a serious public reaming" comes to
mind when I contemplate the outcome.

					Jordan