From owner-freebsd-current  Sat Feb 10 16:29:31 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id QAA24409
          for current-outgoing; Sat, 10 Feb 1996 16:29:31 -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 QAA24400
          for <current@FreeBSD.ORG>; Sat, 10 Feb 1996 16:29:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA29145; Sat, 10 Feb 1996 16:27:21 -0800
To: Terry Lambert <terry@lambert.org>
cc: KentH@HNS.St-Louis.Mo.US, julian@ref.tfs.com, current@FreeBSD.ORG
Subject: Re: FS PATCHES: THE NEXT GENERATION 
In-reply-to: Your message of "Sat, 10 Feb 1996 12:08:16 MST."
             <199602101908.MAA16261@phaeton.artisoft.com> 
Date: Sat, 10 Feb 1996 16:27:21 -0800
Message-ID: <29143.823998441@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-current@FreeBSD.ORG
Precedence: bulk

> I see no philosophical difference from one administrative override
> that modifies the default kernel and another that modifies the
> same file, but operates on different data.

Neither do I, but no proposal so far has covered a mechanism which
would make the maintainance of this data automatic.  In the case of
dset, it's one line which *we* added, and most users don't even _know_
or care about dset, they just know their UserConfig changes are
automagically saved somehow, which is how it should be.

Implement a mechanism as user-transparent as dset for /dev persistance
and I'll more than happily shut up about this.

						Jordan