My First Thunderbird Add-on: Archived-At

E-mail Print

Archived-At add-on for Thunderbird

Being active in various open source communities, I often have the need to refer to previous discussions in my replies or commit messages. So far I manually retrieved the Archived-At URL from the source view of messages from I like to refer to the threaded view, but gmane distributes a URL. So I additional had to edit the link.

For years I wanted to write a trivial extension for Thunderbird to automatize these steps. Then I found the promising extension Archived Link, but it neither worked smoothly nor had the desired UI integration. So I took this and intensive reading of the MDN as foundation to create my first own add-on from scratch: Archived-At.

There are no big plans right now because the add-on does what it is supposed to do from my point of view. Localization, enabling multiple post-processing rules, support for multiple Archived-At tags (provided I find a generating source), those are things that could be done. However, I'm open for feature requests or even patches - it's open source, it can be a community project.

Last Updated on Sunday, 26 April 2015 10:14

Jailhouse v0.1 Release

E-mail Print

JailhouseFrom the public announcement:

After its publication about 10 months ago [first announcement, about a month later], the Jailhouse partitioning hypervisor for Linux reached an important first milestone: all major features required to use Jailhouse on Intel x86 CPUs are now available. We are marking this point with a first release tag, v0.1.

This release particularly means full exploitation of VT-d DMA and interrupt remapping to isolate assigned PCI devices from the hypervisor and foreign cells. Moreover, the usability of Jailhouse was greatly improved by the introduction and continuous extension of a generator for system configuration files. Finally, a framework for writing basic cell applications is available now. With a few lines of C code you can set up timer interrupts, read clocks or configure PCI devices for the use in simple bare-metal real-time applications.

The new release can be downloaded from

It's easiest to try out in a virtual environment provided by QEMU/KVM, see the included README. The braver ones can pick a real compatible machine and let "jailhouse config create" provide a (generally) working configuration. Be warned that real hardware tend to require some manual post-processing of configuration files, for the demo cells or even the system.

Check the project homepage at

for the git repository, links to the mailing list and further information. Don't hesitate to contact the development community on questions, problems or suggestions.

There is still a bit work ahead to reach a version 1.0. In the near future, we will look into integrating recently published contributions of new architectures like AMD64 and ARM 32-bit. An inter-cell communication mechanism will also be merged soon. Several features particularly important for the use in safety-critical scenarios have been identified and are being developed now.

Enabling Jailhouse as a certifiable component in safety-related systems is our primary goal, though we are not excluding other use case like in telecommunication, high-speed real-time control or scenarios we haven't even thought of yet.

Last but not least: Many thanks to all who contributed code, reviews, comments or sponsoring to the project! Your input was already very valuable for the progress of Jailhouse. Keep it up!

Last Updated on Saturday, 30 August 2014 10:26

Reanimating a Zombie: CAPI4Linux

E-mail Print

CAPI4Linux Rescue

For more than 5 years I'm running my home gateway with an ancient FRITZ!Card DSL v2.0. That's a dual channel adapter acting both as an ISDN interface as well as an ADSL modem. It supports up to 6 MBit/s downstream. No longer amazingly fast but still sufficient here. The nice thing about it is that it's only a single PCI card in my gateway box, no external device with additional powering required. But while the hardware is fine, its software sucked from the very first day.

The DSLv2 is pasive card. Wide parts of its lower ISDN and DSL stack run on the host. Only the signal processing is executed on a DSP, basically the heart of this PCI adapter. So the vendor, AVM, kept a lot of its core know-how on the host PC, specifically in the driver binary. Well, you may already guess what this means for Linux: a huge binary blob and a smaller "license adapter" form a proprietary device driver called fcdsl2 - the nightmare of every Linux user and developer.

Yet this nightmare worked more or less reliable for me over the last years. A few hacks were required to get it working with recent kernels and a few more hacks to fix the most annoying bugs. As the locking scheme of this thing always looked suspicious and many people already added various bits to improve it, I cowardly ran my box in CONFIG_PREEMPT_NONE mode. All was fine as long as the DSL connection was up and running.

Unfortunately, DSL links get lost once in a while, cut at least once per day by my provider. pppd was not always able to recover from this. Sometimes a full reload of the driver was required, triggered by a watchdog script. And of those reloads, some ended up in an unresponsive gateway, usually a crashed one. That happened once per month down to once per week - probably depending on the weather or my current bad aura level. Mostly too infrequent to start acting, but still too frequent to ignore it.

So, after another crash cut my home link over Christmas, I finally started looking into this mess. The original plan was to review and fix the fcdsl2, which would likely mean rewriting some parts of it - that was clear. But if I had known in advance how much was broken, well, I don't think I would have started this hack. Not only the driver required a complete locking rework, also the Linux CAPI stack that connects pppd and ISDN tools with the fcdsl2 was part of the problem.

OK, the CAPI stacks has its roots in an AVM driver that was written in the past millennium. That were the days when SMP and kernel preemption were far away from from being common. Some attempts were made to evolve the code towards a proper locking scheme, but the efforts widely stalled many years ago (see history before 2.6.12 and mostly drive-by changes for at least 6 years). So the stack was now in a zombie state: fairly broken inside, not much in use anymore (you can buy ready-to-use DSL+phone routers today), but not yet obsolete as at least a few CAPI-speaking adapters are still around (e.g. Gigaset equipment).

So I started digging my way through the CAPI code:

 Documentation/devices.txt      |    7 +-
drivers/isdn/capi/Kconfig | 3 +-
drivers/isdn/capi/capi.c | 937 ++++++++++++++++++----------------------
drivers/isdn/capi/capidrv.c | 48 +--
drivers/isdn/capi/capifs.c | 126 +++---
drivers/isdn/capi/capifs.h | 21 +-
drivers/isdn/capi/kcapi.c | 797 ++++++++++++++++++----------------
drivers/isdn/capi/kcapi.h | 12 +-
drivers/isdn/capi/kcapi_proc.c | 41 +-
include/linux/isdn/capilli.h | 2 +-
include/linux/kernelcapi.h | 17 +-
11 files changed, 1005 insertions(+), 1006 deletions(-)

The results are 31 kernel patches, mostly touching the user space interface (capi.c), the driver layer (kcapi.c), and the special CAPI filesystem (capifs.c). I did not look very long into capidrv.c, the adapter to the legacy ISDN stack of Linux. That adapter is broken like the rest was. But I'm afraid I would have to continue with digging into the almost obsolete ISDN code, and that is huge. Instead, I decided to replace the last local user of that part, isdnlog from the isdn4k-utils, with a CAPI version, but work on that hasn't started yet.

The series is currently parked in my git tree, waiting for submission after some final stress tests. That should be completed in a few days. Stay tuned for more news from the CAPI front. Next time I will report about my endeavor fixing the FRITZ!Card DSL v2.0 driver itself.

Last Updated on Tuesday, 19 January 2010 09:00

Migration Completed

E-mail Print

The last relevant bits are transfered, the last service is configured, everything runs even smoother than before. I'm now on Debian here, and except for some fights with the exim configuration and the fact that Lenny still delivers a vulnerable buildbot version there was nothing to complain about.

Last Updated on Saturday, 05 December 2009 11:55

vServer Upgrade

E-mail Print

Under construction

The provider of this virtual server, Host Europe, is not longer supporting OpenSUSE. As the release this server is based on phased out recently, I'm now forced to upgrade. The upgrade is free, comes with a more powerful host, more RAM, a few gigs more disk space – but also with a new distro. So I'm going to set up a new server in the background over the next days. All this work should be widely invisible, but Murphy is everywhere and may still cause some downtime as well as several short nights...



Last Updated on Saturday, 05 December 2009 11:55
  • «
  •  Start 
  •  Prev 
  •  1 
  •  2 
  •  Next 
  •  End 
  • »

Page 1 of 2
© Copyright 2009-2014 by Jan Kiszka (PGP Key), Impressum