Contraversial: A New FRUGAL File System? Linux Registry (again)?

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Before the flames start, I realize registries have been discussed before WRT Linux/UNIX.
But I
want to suggest an idea that might make a Linux registry more acceptable. I also want to
present
a kernel module measure for those applications that may never support a registry API.

<flame-retardant>

THE CASE FOR A LINUX REGISTRY (again):

UNIX/Linux people are used to working with small text files to configure components.
Additionally,
Plan-9 takes this even further, making just about everything "a file".  The only problem
with this
approach is that there is a need for each application to parse each of these files to load
a
configuration (but this is the easy part, and not really the issue). Many of these files,
use
different formats, which is a pain for those that don't make a living as sysadmins.

To CHANGE a configuration however, you must obviously text edit the file, or edit a file
that is
sourced from a shell script (but many config files do not work this way). No matter how
you slice it,
you must work with a file that your grandmother may never understand or edit.  This
presents
a problem too, when you want to upgrade with an RPM or debian package, etc. To make
matters worse, this is usually done differently on all Linux distributions.

So to satisfy the editor-challenged-user requirement, this now
places the burden on the programmer to provide something else, to
eliminate the need for a sysadmin in the workstation environment. The sysadmin tool must
digest the config file, apply changes, and then write it safely back out. It is doable,
but just how many config files under Linux actually work this way? Not many,
in my experience.

In fact, right now, it seems that Linux now has a split personality at
this level. Some files say "don't edit.. please use **** tool instead", while others
require that the file itself be edited. Well, make up your mind!

While I am no fan of Windows (of any release), the _IDEA_ of a registry is a good one
(note emphasis on the "idea", and not the "implementation"). The registry "idea", allows a
simple program to make configuration changes on behalf of the user. The user is satisfied
with the point and click ease that the program provides, and yet the programmer is able
to provide a reliable configuration program without a major design effort. Other tidbits,
like the most recently used file etc. are very easy to squirrel away. Under Linux, you
either have to waste a lot of file space, or manage it in an inconvenient, and a
system-wide
inconsistent way (each app does it differently).

A BETTER REGISTRY:

A Linux registry can be implemented on top of just about any reasonable file system,
if you want to ignore the "waste factor" for a moment. A file system provides these
advantages:

  - True UNIX file system permissions at each level (ie. security), perhaps
    even with ACLs someday
  - File system integrity (depending upon the file system of course)
  - The ability to mount or share (NFS) it as necessary
  - The ability to modify/view any entry without special registry tools (use
    standard shell tools if you like).
  - The ability to backup and restore the registry, just like any other file
    system.
  - File locking
  - The ability to monitor the space utilization
  - The ability to have multiple registries, where applicable

I recently did a quick survey of the objections to a UNIX registry idea in google
groups, and the objections can be generally classified as:

   - We don't need no stinken corrupted registries like Windoze
   - We don't like special tools like regedit that don't let you see all of the keys etc.
   - We don't like the security mechanisms employed by the Windoze registry(ies)
   - We don't do it that way under UNIX/Linux (*)

I believe all but the last objection, can be overcome with the right implementation.
(*) Time and proof of concept, may melt away the last objection, eventually. ;-)

A FRUGAL FILE SYSTEM

The real problem with implementing a Linux registry on top of a file system
is that you need a file system that won't waste so much space for
each tiny registry value:

  - where each value is represented by one file (.../key/value is a file)
  - each  key is a directory name
  - each subdirectory is a subkey of the key (key/subkey)

    (or some scheme similar to this)

    I would also suggest that a maximum file size of 8K is probably
   acceptable in a file system like this (larger registry values should
   simply be stored in a file, with perhaps a key pointing to it,
   as a symlink).

For example, if you want to configure a value of the size of an integer (4 bytes),
then usually a file system will allocate 1K (or more) to that file,
wasting 1024 - 4 = 1020 bytes (ls shows the file occupying 4 bytes, but
1020 bytes are physically wasted behind the scenes).

Multiply this by the number of registry values at sizeof(int), and you can
see why this is not a very practical way to implement the idea on just
any file system.

I think something along the lines of the cramfs (without compression) would be quite
suitable for this job. IOW, we need a cramfs that can be mounted Read _AND_ Write,
that was fairly efficient at lookups, allowed frequent updates, and provides a good
fsck for those times where the system crashes (call it something like "FRUGAL").

The FRUGAL file system could be mounted using the loop device to use a
"registry file", or if the user prefers, as another slice of the disk as per usual
for file systems. The file however, may make it easier to grow it, should you
find it running out of space.

HOW ABOUT THEM APPS WITH CONFIG FILES?

Not everyone is going to be eager to migrate apps to use a registry, no matter
how good the registry might be. In fact, some developers may out-and-out say
that they'll "never use no stinkin registry". So what to do?

I think it is possible to provide kernel "bridge" modules for this purpose. For example,
the DHCP server could have a kernel module that takes registry values from
a designated FRUGAL (registry) file system, and then present a ordinary text file
in the proc file system as /proc/etc/dhcpd.conf, based upon all of the known
registry keys as input. So when /proc/etc/dhcpd.conf is opened, the kernel
module can collect all of the registry keys and assemble them into a text
file on the fly, in typical proc file system fashion.

You could also symlink /etc/dhcpd.conf to the /proc/etc/dhcpd.conf, and the
application need not be the wiser. Other major apps could be handled
the same way. Once the first bridge kernel module is written, many others
can be quickly cloned from it.

Once this infrastructure is in place, a number of small pieces of information can
be easily handled in the registry (in the FRUGAL file system). This would make
configuration of servers and workstations much easier than it is now, and it
would make good use of the available disk space. It will still be the "UNIX
way", except that we've now moved parameters to the file level, rather than
grouping all parameters into one file.

THE REGISTRY API:

Once a "frugal" file system is implemented, then a registry API can be developed
to layer registry concepts onto the file system, in a developer convenient way
(in library section 3C).

In this way, the developer is relieved from doing directory searches, defaults,
etc. handling. A value fetch or change could be performed in one (or few)
API calls, rather than many. The idea is to keep the API to a minimum, to
make it easier for developers to provide configuration tools (GUI and otherwise).
We can also learn from the design mistakes made by that other OS ;-)

We need NOT use the same "design" as Windows (no backslashes please!), but
we might want to provide the optional capability to store and retrieve windows
like keys, to accommodate Windows things like Wine. This makes porting
some Windows apps to Linux just a little bit easier.

SO WHAT IS THIS BLATHERING POST ABOUT?

I personally see this registry thing in Linux as an itch that needs scratching. However,
I've neither the time or the developed talent to do a full fledged file system. What
I was hoping to accomplish from this post, is to get people thinking more about the
idea to hopefully find some eager soul to run with it.

Maybe someone out there is itching for an excuse to develop yet another file
system? Now you have an excuse ;-)

While the Windows development environment is an abomination (IMHO),  what
it does have going for it is an easy way to configure and install things on it. At the
same time, I don't like losing control of what's going on. I think a file system
approach with the appropriate API layered on top, provides an acceptable
compromise to both views.

Finally, by implementing a registry this way, all we have done is taken
the file concept FURTHER, down to the paramter level.

Rather than have one file group all parameters (which is done to save space),
we separate each parameter out to its own file. This makes parameters
real easy to query, change and display. To make this practical, we need
a FRUGAL file system to implement a registry.

I am personally growing weary of RPM updates, and debian updates that look
at the config file and say "I can't do anything with this, so I will just rename it
and put the new template one in its place for your editing". Folks this is
not good enough. I think we need a solution to this problem. I think we
can do. Much of the framework is nearly there. Someone just needs to
take the idea, and integrate them.

    Surely, there has got to be a better way!

<begging>

ANY TAKERS?

If you are interested in this idea, and you want discuss ideas privately (perhaps
to avoid flames?), then email me directly at:

    w a r r e n   <at>  c o g e c o . c a

I would really, really, like to see something done for Linux configuration.

(the above email address is designed to avoid spam, since my main mailbox is
getting e-bombed by worms still).

</begging>
</flame-retardent>
-- 
Warren W. Gay
http://home.cogeco.ca/~ve3wwg