Here’s a fun game I sometimes play on OpenBSD. Pick a directory under src and see what’s in it. (ok, it’s not Skyrim, but it’s also free to play.) I recently switched from being an i386 holdout to running amd64 and so this seemed like a good time to see what’s hiding under the libarch directory. libarch is an assortment of code specific to each platform that’s wrapped up in a convenient place, even though it’s completely unportable. What surprises will we find in the amd64 subdirectory of libarch?

There’s a function amd64_get_ioperm. Read the man page to find out what it does, which says it takes a pointer to u_long and then explains “The permission bitmap contains 1024 bits in 32 longwords.” From what we know about integer sizes this is clearly wrong. 32 x 64 = 2048. But is the right answer 16 words or 2048 bits?

Read the source for the .c file. It very simply calls sysarch, the arch dependent syscall, with the same argument. Into the kernel we go. In sys_machdep.c we finally find the implementation. Or what would be the implementation if it weren’t #if 0 disabled. But there’s enough code left to see it’s referring to an array in struct pcb (Processor Control Block), which is used to maintain state for a process during context switches. Except that array doesn’t even exist. Great, lots of obsolete code to delete, delete, delete. Still curious, though, I asked what does this code look like on i386?

Ah ha, on i386 we finally find a pcb that contains an iomap. It also contains something else, a struct emcsts supposedly used by some Cyrix coprocessor which not only is clearly not supported, but which I’ve never even heard of. What is that doing here? As near as I can tell, it was part of a larger FPU support package/library that was integrated into NetBSD ages ago. In any case, it too has an appointment with the axe.

Did deleting this old code make things better? Maybe a little. It was small enough and out of the way to not interfere with anyone’s development, and clearly wasn’t a maintenance burden or somebody probably would have noticed how irrelevant it was ages ago. Sometimes when we go looking for code to fix, we just find code to delete. Never know until you begin. The important part is to start by finding code.