Blog

The buildd admin job is a rather dumb one. You get between 20 and 60 mails per day; most of them build logs. This logs, which are mostly sent unsecured through the public internet, have to be signed and the only available key is the personal key of the admin. So on one hand you have to make sure that the key is secure, on the other hand you have to find a way to sign a rather large amount of stuff.

For the debian-kernel archive, which I operate, and the pkg-voip/pkg-gnome/pkg-kde-extras archive, which is operated by Kilian, we decided to sign the uploads automaticaly. Each buildd get its own key and the used DAK includes a patch which restricts this keys to do uploads of only binaries of the correct arches.

This drasticaly reduces the time until a new package is uploaded; this means much less failed builds because a build dep is not yet built. Also it reduces the places where it is possible to do harm; you have to attack the buildd machine itself instead of the complete mail setup between buildd and admin.

Why is there no automatic or at least semi automatic infrastructure for LSB tests? The last published result is from the beginning of the last year and only for sarge.

The upcomming linux-2.6 release will introduce some changes in the Xen support.

kernel: xen_net: Memory squeeze in netback driver.

I just take a look into the opcodes list of binutils for s390 and found the following entries:

b9b1 cu24 RRF_M0RR "convert utf-16 to utf-32" z9-109 zarch
b2a6 cu21 RRF_M0RR "convert utf-16 to utf-8" z9-109 zarch
b2a6 cuutf RRF_M0RR "convert unicode to utf-8" z9-109 zarch
b9b3 cu42 RRF_M0RR "convert utf-32 to utf-16" z9-109 zarch
b9b2 cu41 RRF_M0RR "convert utf-32 to utf-8" z9-109 zarch
b2a7 cu12 RRF_M0RR "convert utf-8 to utf-16" z9-109 zarch
b2a7 cutfu RRF_M0RR "convert utf-8 to unicode" z9-109 zarch
b9b0 cu14 RRF_M0RR "convert utf-8 to utf-32" z9-109 zarch

Since z9-109, it have own opcodes to convert between the different types of unicode.

It is done. The new Xen infrastructure is finished, although it is not yet completely in unstable.

The main difference to the old one, the hypervisor and utils packages includes the complete version and an abi spec, just like our linux kernels. Also it is now possible to install more than one version of the utils at the same time. The userspace tries to find the correct tools for the running hypervisor.

The following packages are provided now:

• xen-hypervisor-3.0.2-1-$flavour
• xen-utils-3.0.2-1
• xen-ioemu-3.0

and from the kernel

• xen-linux-system-$kernelversion

The only missing thing is a selection of the correct hypervisor in update-grub.

I did some performance tests with the T2000. The CPU is too slow to beat any current one from IBM (Power), AMD or Intel.

My first test was building kernels. With -j32, a complete build needs about 9 minutes. For comparison, a 4-way UltraSparc 2 with 450MHz needs 30 minutes. So each core compares to an UltraSparc 2 with 700MHz.

This numbers are not that phenomenal, so I added another test with ccache, to realy use the io system. With empty cache, it needs 10 minutes, with filled cache it needs 2.5 minutes.

As application server, it is not that usable; they are cpu bound. Especially zope, which is known to not scale well on more cpus because of the python global interpreter lock, is not able to use this. A comparision with an Opteron 242 with 1.6GHz shows a factor of 5 in the computing power on virtual cpu.

Some people already know it, I got a new machine to play with.

It is a Sparc running Debian etch:

# uname -a
Linux zee 2.6.17-2-vserver-sparc64 #1 SMP Sat Aug 26 12:28:58 UTC 2006 sparc64 GNU/Linux

The kernel is not yet available in Debian, it is handbuilt. But I hope that this will change soon.

It is a small machine with some CPUs:

# grep ncpus /proc/cpuinfo
ncpus probed    : 32
ncpus active    : 32

It only have a little bit of RAM:

# grep MemTotal /proc/meminfo
MemTotal:     33257432 kB

And really too less disk space:

SCSI device sda: 143374738 512-byte hdwr sectors (73408 MB)
SCSI device sdb: 143374738 512-byte hdwr sectors (73408 MB)

Yes, it is a T2000 from Sun with 8 real CPU cores:

cpu             : UltraSparc T1 (Niagara)
fpu             : UltraSparc T1 integrated FPU
prom            : OBP 4.19.0 2005/10/27 17:24
type            : sun4v

Each of the 8 cores can run 4 threads at the same time, Sun calls this CoolThreads, and Linux sees this as virtual CPUs.

Yes, the xen images from linux 2.6.16-18 in unstable does not work with the currect xen 3.0 in unstable and testing. The interface for the priviledged domain changed in an incompatible way. I'm working on that problem and 2.6.17-7 will contain a complete new infrastructure.

I think the current situation is rather clear. Our current kernel contains firmware blobs for some hardware. They are relicts from the time where the firmware loading infrastructure did not exists. It may be possible to move them outside, but such patches was rejected to keep compatibility.

Some people clearly stats, that they think, this violates paragraph 2 of the DFSG. I must say, I'm not sure. This paragraph say: The program must include source code. Now source is not defined and opaque data have no defined form of source. The data is opaque as it is not possible to say, what it includes. (Some people wanted to differentiate between executable code and configuration settings, but there is no way to see what it is.)

If we remove them from the kernel image, we make many users unhappy. Many of the widely used hardware like TG3 and some storage adapters will just stop working after a kernel upgrade. There is also no clean upgrade path. Even the installer infrastructure is missing and I don't think they will be finished for the release of etch. Therefor is think, such a removal will even violation paragraph 4 of our Social Contract which say: Our priorities are our users.