Subject: Re: proposed: changes to "etc" (?)
To: Rick Kelly <firstname.lastname@example.org>
From: Paul Evans <email@example.com>
Date: 12/13/1997 00:06:33
On Fri, 12 Dec 1997, Rick Kelly wrote:
> Matthew Jacob said:
> >Fair enough. However, as the number of computers running in the
> >world that require lights out sustainable operation increases,
> >unless we clone you, I predict that even you will beg for this
> >property within five years.
> The problem with ODM and Windows registry is that they can easily
> become trashed to the point where one must re-install the OS.
> NT and 95 seem to regularly trash the registry.
NT and 95 are not reliable is many other ways! However, I'd hate to gauge
the value of registres as a whole by using M$'s implementation as the
sample. NT/95 implemented a binary version of the win3.1 \WINDOWS\ dir.
I've only heard good things about VMS configuration on the other hand.
I'd be intresting in hearing about problems from VMS administrators.
> I wouldn't want an OS that has no administrator serviceable parts
Neither would I.
I'm advocating a kernel support mechinism that allows us to have a
file type than can support locking (by "line" or "entry") , versioning,
and syntatic checks.
I think maybe the easiest way to support something like this is not to
change the VFS code too much. But to use a VFS passthrough layer that
allows a file to be assocated with a "manager" daemon. The vnode driver and
portal/union FS both already provide much of this capability.
I'm picturing a method where a specfic file is assocated with a specifc
type (hence a specfic manager), a user mode agent actully verifys and logs
all changes before they're saved to disk.
For example, we could have a generic text file "manager" agent. It would
have it's own configuration table (By necessity). A sample rule for the
hosts file would encompess the knowledge:
"/etc/hosts is a host_file and contains 3 three alphanumerics per line,
an IP, a host and an FQDN. The # comment character is valid."
The kernel would then relay all r/w requests to the daemon, the daemon
would verify/log and return the value to be returned from the
open/read/write call, as well as doing the actual r/w.
I'd like an opnion on this as I think it's a good framework for providing
both an enhanced configuration mechinism, HSM, and an ACL mechinism.
I'd like to start work on this in my free (hehe) time, if no one thinks
it's too wacky of a idea. (I guess it needs to be nailed down a little
> Rick Kelly firstname.lastname@example.org email@example.com
firstname.lastname@example.org _ email@example.com