Older blog entries for tjansen (starting at number 3)

21 Sep 2001 (updated 21 Sep 2001 at 10:24 UTC) »

Originally I wanted to keep out of the WTC-related discussions here because I still consider Advogato a OpenSource-related site... but yesterday they showed something in a german tv magazine that I have to tell the world about.

Remember the CNN pictures of the palestinian people celebrating? German magazine "panorama" showed the complete shot. There you can see that the life over there went on as usual, only a few children celebrating because a guy in a white t-shirt motivates them to do so. It also shows that the old woman who celebrates does so because they offered her cake, and she later denied that she did it because of the WTC attack.
You can watch the clip in Real format here. It's a 10 minute movie in german, so you have been warned. You can find the CNN/palestinian part at 7:40.

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.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!