caurea.org

Let me say it straight away: I strongly disagree with section 5.3 of RFC 3493 that IPV6_V6ONLY should be disabled by default. With this option disabled it's impossible to create a server socket in a truly protocol-independent way.

When RFC 2553 was published in 1999 it described a set of functions which can be used to enumerate and resolve socket addresses in a protocol-independent way. But with the release of RFC 3493, and its introduction of IPV6_V6ONLY, the protocol-independent aspect of these functions has been largely lost. The following example shows why:

One of the functions described in RFC 2553 is getaddrinfo. This function can be used to get a list of socket addresses suitable for bind'ing a server-side socket. On dual-stacked hosts it will return two addresses: one for IPv4 and one for IPv6. But when IPV6_V6ONLY is disabled, you can't have two sockets bound to the two addresses, the second bind will fail with EADDRINUSE. You can either find out which addresses of those returned are IPv6 and use only those, or you can enable IPV6_V6ONLY. But as you see both of these solutions aren't really protocol-independent anymore.

From what I gathered most *BSD distributions have IPV6_V6ONLY enabled by default, only Solaris and Linux don't. At least Debian is starting to break the ice and enabled IPV6_V6ONLY in their latest netbase package (4.40). That has broken a few other packages, but as the bug headline says, those are buggy and thus need to be fixed anyway.

The primary OS on my ThinkPad laptop is Gentoo. I've intentionally chosen the amd64/no-multilib profile, meaning that portage compiles and installs only 64bit libraries and applications. That also means that I can't run any 32bit applications such as most closed-source apps that are available only in binary form (Skype comes to mind) or Windows games which run under Wine. Even though I do fine without, sometimes I do want to run those apps. But at the same time I want to keep my system clean of 32bit cruft. For me the solution has been to install 32bit Ubuntu in a virtual machine. However running software in a VM comes with a performance penalty. And in case of games that is just plain unacceptable.

Dual booting would give better performance, but when I just need to quickly run a 32bit app I don't really want to reboot the computer. So I settled for a hybrid solution: Install 32bit Ubuntu so that I can boot it as host or as guest inside the Gentoo host. The basic approach is described in a section of the ArchWiki page about QEMU: Using any real partition as the single primary partition of a hard disk image. I only had to adjust the size of the mbr file, 16 Kilobytes was too small. I created a four Megabytes file (dd [...] count=8192) and set 256 heads, 32 sectors in fdisk so that the first partition can start at cylinder 2. After building the md array, I started kvm and installed Ubuntu. One thing I paid attention to is to manually set up the partitions, to prevent the automatic partitioning tool from moving the beginning of the first partition.

To make the system bootable directly from the BIOS I had to copy the Ubuntu kernel and initrd from the Ubuntu partition into my Gentoo host and then update lilo appropriately. Be sure to first stop the md array (mdadm --stop /dev/md0) before you mount the partition! The entry in my /etc/lilo.conf looks as follows:

image = /boot/vmlinuz-2.6.32-9-generic
    label = ubuntu
    initrd = /boot/initrd.img-2.6.32-9-generic
    read-only
    root = /dev/sda8

Then I only had to run lilo to update the boot manager and voila, now I have a new entry in my lilo prompt: ubuntu. Selecting that boots the 32bit Ubuntu system. And whenever I'm on my Gentoo host and quickly need access to the Ubuntu system, I simply build the md array and boot it with kvm.

In case you are wondering why I have eight partitions (the Ubuntu system installed in /dev/sda8): I have partitions for swap, root, home, pool (large files, games etc), priv (was supposed to become an encrypted partition, but I don't use it for anything right now) and then three 20GB partitions for virtual machines. I created the three partitions so that the VMs can access the harddrive directly and avoid the overhead of the filesystem. Also, because MSDOS partition table can only access more than four partitions with quirks (extended partition), I decided to use GPT which supports up to 128 partitions. Unfortunately GRUB doesn't support GPT yet (version 2 does, but that is still under development) so I had to settle for lilo. But I don't mind because I don't need the additional features that GRUB provides anyway.

A couple months ago I used the clang static analyzer on my MacBook. At that time the tool still yielded many false positives. Today I decided to try to get it running on my Linux laptop, mainly so I can run it on some of the source code I have stored there.

The static analyzer is available as a binary package for MacOSX, but if you are on a different platform you have to compile it manually. That was not a problem and the source compiled cleanly. Just follow the instructions and you'll be fine.

When I first tried to analyze a bigger project, it failed because clang couldn't find the stddef.h header. But because my system had about four versions in different directories, it wasn't easy to find out which one was the correct. The obvious choice to me was to add /usr/include/linux to the header search path, but that didn't work and clang failed with even more errors. After a bit googling I found out that it needs the file from the gcc compiler. On my gentoo box it is stored under /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include. In case you don't know your chost and gcc version, you can use this command to automatically determine the path: /usr/lib/gcc/$(gcc -dumpmachine)/$(gcc -dumpversion)/include. In the end, I had to add these two paths to CFLAGS:

• /usr/lib/gcc/$(gcc -dumpmachine)/$(gcc -dumpversion)/include (stddef.h and friends)
• /usr/lib/gcc/$(gcc -dumpmachine)/$(gcc -dumpversion)/include-fixed (limit.h)

After that I was able to successfully analyze transmission, the X.org xserver and git. I also tried the linux kernel, but it uses way too much black magic for clang to handle.