[RFC] Standard Sytem Config Filesystem (has /proc and devfs implications)

From: dg50@daimlerchrysler.com
Date: Tue May 09 2000 - 11:13:13 EST


There was some minor discussion on this last week, and I'm folding feedback
from that into this post.

The major target for this proposal is the Linux Standard Base folks, but my
(perhaps entirely mistaken) impression is that the LSB is a little more
politically driven body than linux-kernel, where it seems like "what's
Right and works well wins". As well, there are some small kernel-space
issues with this proposal that I'd like to get feedback on from the people
who maintain those actual portions of kernel space. I feel that if this
gets discussed here first, that I/we have a better chance on getting the
LSB to listen and that the end proposal will be of much higher quality.

Given the following:

1) Having a _single place_ in the system filesystem, organized in a
reasonably structured manner, to contain system-wide configuration files,
is a Goodness.

2) Having ASCII-text configuration files (as opposed to binary data fields)
is another Great Goodness.

3) The current /etc filesystem is a rough approximation of Item 1, but
there are some serious flaws:
     a) The files in /etc are not well organized, and for the most part,
are not organized at all. /etc is for the most part a great big bucket.
     b) Not all system config files live in /etc. Some are scattered
pell-mell throughout the system. Most noteable here is parts of /proc,
which, when altered, directly affect the operation of the system.

The proposal is to clean up and organize the /etc filesystem by defining a
structure and then, over time, changing system daemons, the kernel, etc to
point to the new structure. Key points:

1) Either rename or create a new parallel /config directory. (Optional - I
think /etc is as good a name as any, but several people have indicated
they'd prefer a new, more explicitly named root directory)

2) Provide the following subdirectories. s/config/etc/ if it bothers you
too much:
     /config/dynamic - for the various subtrees in /proc that are
config items but non-persistant across reboots.
     /config/devices - for device/devfs config files
     /config/network - for network connection config files
     /config/X11 - for X
     /config/filesystems - for fstab, NFS, etc
     /config/kernel - for persistant files that affect kernel
operation or installation (lilo.conf, etc)
     /config/services - for daemon or system service config files
(/config/services/bash/bashrc, /config/services/slapd/slapd.conf etc.)
     /config/bootscripts - for system startup scripts
     /config/security - for password/group files, cert storage,
kerberos
     /config/games - for games
     /config/local (/config/opt) - for locally installed package
configuration files.

3) Establish the following guidelines:
     a) No bare config files in the root /config directory - everything
must be at least one level down
     b) For "container" directories (/config/services, /config/games, etc.)
no bare config files. Instead, they must be a level down in a <package>
directory. Thus "/config/games/quake4/quake4.conf" not
/config/games/quake4.conf

4) (far future) Establish a format and API (possibly within the C library,
but maybe standalone) for create/read/modify /config entries (much the same
way that /proc is going to a similar API) and then have the kernel and the
othe system-wide programs ported to use it.

Comments are welcome.

Aside from the following: :)

     - "That's not UNIX" A. That's not UNIX *yet*. UNIX can and may evolve
just like anything else.
     - "You'll face huge resistance from traditionalists who hate change"
A. Quite probably. So what? If the technical merits make the effort worth
doing, then IMHO it's worth doing, despite the degree of difficulty.

Comments on the technical merits (or lack thereof) are highly welcome. :)

DG

-
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 : Mon May 15 2000 - 21:00:14 EST