[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [desktop] Unix configuration nightmare



Hi,

On Tue, Oct 22, 2002 at 09:05:10AM +0100, Mark Howard wrote:

> Hi,
>   There has been much debate about unix system configuration [0]. This
> has resulted in discussion and even a message of support from the fsf,
> however no actual work has been done.
> 
> [0] http://www.cat.org.au/maffew/cat/unix-config.html
> 
> The main options seem to be:
> - Write an entirely new configuration format to be used by all programs.
> Write friendly programs for editing these

That'll only work if the format and the API are so compelling that
everyone will want to use them. So far, that hasn't been the case.

I think that will only be the case when the API is unix and the format
is the filesystem itself. Considering that 99.9% of all configurations
files can be represented as some tree of nested attribute/value pairs,
why not?

Why the hell would we want some shared library that would have to be
adopted by everyone, that implements MyFancyUnixRegistryOpenKeyExA(),
MyFancyGetKeyHandle(), MyFancyAddValue() and so forth (yuck!), when we
have open(), read(), write(), readdir(), close()? 

The unix model has served us well, from block devices to mice,
soundcards, and hierarchical storage databases (the filesystem); why
would it suddenly not be useful when we need a configuration registry?
The problem is not the model, the problem is that we don't take the
model far enough, and extend it to the individual configuration items.

A few things are needed on the kernel side for that, but these
modifications are probably better aligned with unix philosophy than
'just add another syscall', which seems to be the trend in Linux these
days.

Of course, what we need at least is a filesystem optimized for lots of
very small files. ReiserFS gets us a long way in that, but I think we
need to go even further if we are to tackle things like backwards
compatibility.

If Linux could have an efficient channel to talk to user space
filesystems, you could easily write filesystems that use an existing
configuration file format as their 'on-disk' filesystem layout, and
distribute that together with the application that uses the
configuration file. Then, if those filesystems could be used without
loopback block devices (i.e. if the distinction between block devices
and real files can be removed when it comes to having a filesystem
access it), then we've both solved the problem of allowing certain
configuration files to have certain formats optimized for them, and the
backwards compatibility problem, allowing a smooth transition to open(),
read(), write(), close() [1].

This may all sound way too revolutionary perhaps, but keep in mind that
if these things could be implemented on Linux, we also realize one of
the most important dreams of the Hurd (user space filesystems, without
special privileges), without having to give up the good parts of Linux
(maturity, drivers, developers, momentum).

What do you think? Smack this guy with a clue bat, or good idea? I'd
like to hear both.

Cheers,


Emile.

[1] Notes: 1. Of course there are locking issues; mandatory locking at
the open() level between opening the file itself and the 'files' in the
filesystem contained in it is probably necessary.  

2. Perhaps it's possible to use a #!/lib/fs/rcfile or something in the
inode structure to tell the kernel what user space filesystem to
launch/mount 'on demand' if a nonexecutable file is referred to as a
subdirectory in a path. The Hurd also has a mechanism like this.

3. Off topic: if you go a step further and implement a /dev/irq/1 etc.
that can be open()ed and select()ed, then people can also start to
implement user space drivers, wherever convenient - perhaps even slowly
turning Linux 'inside out' eventually. The other bits of user space
programs accessing hardware are already there; look at X. Then, only the
drivers that demand extremely low latencies or that are needed by the
kernel for other things than supplying user space with a open, read,
write, ioctl, close API to the need to stay in kernel address space.

In short: I think that the Hurd's ideals can be achieved without giving
up Linux, while even gaining a unified representation for configuration
files.

-- 
E-Advies / Emile van Bergen   |   emile@e-advies.info
tel. +31 (0)70 3906153        |   http://www.e-advies.info

Attachment: pgpZp_JT_kbUg.pgp
Description: PGP signature


Reply to: