devreg: The progress of the device registry is ok but could be better. Coding of the framework is finished, I still have to add the new registration stuff to the drivers and then hope that everything works fine without too much debugging. Beside that I started writing the documentation for driver developers. I think this is the right time to do this since I'm pretty confident that most of the kernel API will be stable from now on.

config fs: I'm planning to abandon my proc fs changes in a future version and instead write new filesystem based on the proc fs code. Proc FS is a mess. While most of the files in /proc are quite convenient to read for human readers they are almost unusuable for software. The problem is not that parsing would be so difficult but that it is impossible to add new fields once you have defined a text format without breaking all software that reads it. Binary files suffer from the same compatibility problems. A few months ago several people convinced me on LKML to go the "one-value-per-file" way for devreg, and the new filesystem will enforce this even more than my proc fs extensions. Every file will be strictly typed (string, int, ulong, enum), dynamic directories will be possible, the type of a file can be retrieved using ioctls, and unlike my current proc changes writing will be supported, too.
The more interesting part of the plan is that I want to support both persistent and non-persistent files. So there will be some daemon waiting, similar to devfsd, for files that have been flagged as persistent and will then store their new values when they have been changed. On initialization of a file the daemon will fill it with a previously stored value. Dynamic directories can have keys that can be used to find the correct one. I'm currently calling this concept config fs. Beside the replacement of proc fs for everything but processes it can be used for the configuration of the kernel and drivers. The current way of configuration definitely sucks, module options are a bad idea for most purposes because you cannot change them at runtime and they are not very useful if your driver handles several devices at the same time. They can only be used for the driver's global configuration, but not for the configuration of driver instances. IMHO module options should disappear for anything but boot-time configuration. The only frightening thing about the config fs idea is how close it is to Win2k's registry. It's a little bit less arcane because you can access it as a filesystem, but beside that there are only few differences between them. It could even make sense to use it for the general configuration of system software. bah...