dg50@daimlerchrysler.com writes:
[I wrote:]
> > There's nothing special about /proc-related stuff (as opposed to
> > other configuration state in /etc). i.e., the *user* shouldn't need to
> > care that `this stuff is managed directly by the kernel'.
>
> Well... there is the thing that manipulation of the /proc stuff
> _immediately_ changes the system, whereas that may not be the case with
> other files.
This is already inconsistent; changes to /etc/fstab and /etc/passwd
take effect immediately, for instance.
> As well, (and perhaps more importantly) changes made to the /proc items are
> not persistant across reboots. If they get intermixed amongst the "real"
> files, you have inconsistancy in interface.
Argh, I forgot that. OK, so there *is* something different about /proc's
semantics, and something that is hard to fix. Hell. A userspace daemon
and some coda-like kernel callbacks to notify the daemon when things
change could fix that and preserve changed stuff, but I think, well,
that's a bit ugly, devfsd notwithstanding.
> > (The far end of this is something like a database-in-a-filesystem, with
> > views instead of directories ;) )
>
> Yeah... every time I follow this out to its logical conclusion, I wind up
> with /etc (or /config, or whatever) as an LDAP directory, complete with
> IDEF-defined schemae and so forth....
I was thinking more like CORBA.
> Bleah. Text files may be sub-optimal in certain cases, but they're *easy*.
Agreed. This is overdesign we are perpetrating here. I shall go and sit
in the corner and beat myself over the head with the OS/2 Workplace
Shell manuals, in penance and as a terrible warning to others.
-- Root beer --- the drink of the BOFH.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:19 EST