This is slightly old news now, but I've decided to starting blogging and this seems like a good place to start.

At this year's debconf in Nicaragua I finally got around to applying to be a Debian Maintainer. Thanks to the various people who advocated me (and prodded me to apply in the first place!). My key was added to the DM keyring in mid-August.

I intend to continue to maintain the various IVTV capture card packages that I maintain (ivtv-utils and xserver-xorg-video-ivtv) as well as continuing my involvement with the packaging of Xen and associated stuff like the kernel and installer. I also plan keep working on improved support for the DreamPlug, for which I have a few fixes queued up for post-Wheezy already.

More recently I've bought a QNAP TS-210 (which is a nice little NAS that can run Debian) and ended up adopting the qcontrol package, which ended up being my first actual upload to Debian!

Anyway, hopefully I'll manage to post here at least semi-regularly.

No sooner had Henrique de Moraes Holschuh announced the availability of improved microcode updating in Wheezy (sadly non-free) than Stephan Seitz pointed out that this support was broken for systems running Xen, which is unfortunate since as Henrique notes the impact of not applying such an update could be pretty much anything.

There's a bit of a saga here: a patch has been available for several years which adds Xen support to the kernel's microcode driver in a nicely self contained way. However the Linux maintainers have decided that loading microcode from the kernel is too late and it should be done earlier (e.g. by the bootloader, or some shim between the bootloader and the kernel) in order to be effective and on that basis rejected the Xen patch implementing the existing kernel based scheme.

In the meantime Xen has implemented early loading of microcode via an additional multiboot module passed by the bootloader and this was released in Xen 4.2 in September. (so far I've not seen any progress on making any change to the native side but that's by the by).

However Wheezy is going to be shipping with Xen 4.1 which doesn't yet have this support in it. So we are basically faced with two choices, either we backport the support from Xen 4.2 or we apply the kernel patch.

The downside of backporting rather than taking the kernel patch is that the backport is non-trivial (although not totally unwieldy) while the kernel patch is pretty much entirely self-contained.

The other downside of early the early loading scheme in general (for either native or Xen) is the need to update tools (e.g. update-grub) as well as modifying the microcode packaging to put the files somewhere that the bootloader can see them (so /boot). This certainly can't happen for Wheezy at this stage which basically rules out the backport approach.

So, the upshot is I've filed Debian bug #693053 and applied the kernel patch to our tree. It's all a bit unsatisfactory but at least microcode loading will work for users running Xen on Wheezy.

With any luck for Jessie the native early microcode loading code will have landed as well and the pain of the infrastructure updates can be shared.

A little while ago Michele Cane filed Debian bug #689912 against qcontrol asking that the package install the correct configuration file for a TS-419P II, a newer device which has an LCD.

It turns out that to support devices with LCDs properly we need to probe a GPIO line in order to figure out if an LCD is attached or if a serial console is in use (since the two are mutually exclusive on this hardware, when you attach a serial console you must toggle a jumper too).

This actually turns out to be rather trivial since qcontrol's configuration files are actually simple Lua programs and the state of the GPIO lines can be accessed via sysfs and so we can read the state directly from the configuration file itself.

While looking into this I happened to notice that the various board-specific configuration files are actually very similar and that the differences can all be detected by a combination of the Hardware field in /proc/cpuinfo and the GPIO lines.

So I started looking into whether I could write a single consolidated qcontrol.conf file to replace the various variant specific files. It turns out to be quite possible, the resulting consolidated file has been posted to the bug log (see also my mail).

The danger with configuration files which are also fully-fledged programming languages is that there is a temptation to write more and more complex configuration files with the danger that the primary purpose of the file (configuration) can be obscured. I think in this case it is a close call but on balance I think the downsides outweigh the advantages, so I've uploaded qcontrol 0.4.2+svn-r40-2 which simply adds LCD support to the relevant board specific configuration file.

In process of doing so I seem to have fallen into a trap which seems to catch out many sbuild users at least once and uploaded a package with "UNRELEASED" still in the changelog. To try and save myself (and others) some blushes in the future I've filed Debian bug #693841 (wishlist) against dput to see if it can catch this case, I've also added to my prerelease checklist.

As it happens my own TS-419P II arrived today. I intend to use it for second tier storage (mythtv recordings, music, mirrors) as well as light server duties (MTA, internal DNS etc) which should allow me to turn off the existing PC in the cupboard under the stairs which is getting a bit long in the tooth and starting to become a bit unreliable (I also suspect its costing a fortune to run).

For the last few weeks I've been working on getting Xen running on 64-bit ARM (AArch64), using the Fast Models. This morning I finally solved the last bug (a pretty dumb one as it turns out) and booted domain 0 to a prompt! A screenshot is worth 1,000 words, although you'll just have to trust me that this is running under Xen :-):

At the moment I'm using the same 32-bit dom0 kernel as we run on the 32-bit port of Xen, obviously we eventually want to support both 32- and 64-bit guests. In fact we went to a fair bit of trouble with the 32-bit port to try and ensure that the hypercall ABI would be the same for both and avoid the need for a compatibility layer (Stefano's talk from XenSummit in the summer has some details on that).

Combined with Debian bug #599161 finally being tracked down and fixed upstream all in all this is shaping up to be a pretty good week!