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:
pgpzgo8rlw9Oy.pgp
Description: PGP signature