Subject: Re: proposed: changes to "etc" (?)
To: Rick Kelly <>
From: Paul Evans <>
List: tech-kern
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
> inside.

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

	Paul Evans _