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...

I just wanted to point On2's
VP3 codec that has been released in source form
yesterday because it did not get as much press as it
deserved,
IMHO. VP3 is a very good codec with MPEG4-like quality,
even if it is not their latest version (VP4). The license
is a MPL with a compatibility clause: you are not allowed
to
take the code or use their patents to build something,
that does not (also) encode or decode VP3 streams. While
not perfect, it should be good enough to make me happy. It
is at least better than the MPEG codecs that are poisened
with patents.
The source code has not been ported to Linux/Unix yet
though,
they just released the source for their Quicktime and VfW
codecs.

I'm currently extending the device registry
with a registry for drivers. It started as a simple idea
to solve the problem of displaying several drivers that
handle a single physical device. This is quite
complicated as I use one-value per /proc file, so a list
of values means creating a dynamic directory for
enumerating them. I thought of creating a directory per
driver and linking from them to the devices instead, which
turned out as being a great idea. This does not only allow
me to
make more information about the drivers available, but
moving the devfs node descriptors to the drivers solved
some problems with finding the right node of unusual
devices that have, for example, several nodes with the
same interface. Even more important, I can now add device
node ids that can be persistent identifiers of a physical
device's devfs node (or major/minor number). This will
make libdevreg much easier to use: if you want to find a
device node just use its id as an argument to the find
function. But even better, I now have an easy solution for
having stable minor numbers in the kernel. Just fill a
table (with the help of a /sbin/hotplug-style user space
program) that maps device node ids on minor numbers.
As a timeframe, I hope to have a version of devreg without
the stable minor number thing ready in two or three weeks.

I am also writing on a system similar to the minor number
thing but for major numbers with the major name instead of
the device node id. It will hopefully be ready at the
same time. This would solve Linus' decision of not
allowing any new major numbers as it moves the major
number location from the central register to the
user or his distribution. I haven't seen any other patch
doing this, which quite surprises me. However, I need this
code for the device node id / minor number mapping.

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser
code is live. It needs further work but already handles most
markup better than the original parser.