Becoming a kernel developer
After a fair amount of clean-up, a lot of waiting for review, and some ruthless pruning, I and my colleagues at Solarflare finally got our net driver accepted for Linux 2.6.26. Meanwhile a larger version of the driver made it into Xen's Linux tree, along with dependent drivers to provide a secure fast path to the hardware from domU. Somewhere down the road we're going to have to resolve these two versions, but now I'm just pleased to have a working driver in-tree.
There are some other changes I've worked on over the past few months:
- I maintain diagnostic scripts for our NICs and drivers. Among other things they include Vital Product Data (VPD). There's a standard way to read VPD in PCI (actually there are two, in different versions of the spec) but in Linux this is only accessible to root, and even then there are race conditions. We provide an MTD driver for flash and/or EEPROM attached to the NIC, and I know where the VPD appears in there, but most users won't be loading that driver. So I wrote this: Expose PCI VPD through sysfs
- Along the way I found a bug in sysfs, which I fixed: Disallow truncation of files in sysfs
- One day I accidentally bridged one of our network interfaces, which has Large Receive Offload (LRO) enabled by default, with one of the motherboard's network interfaces, and the results were not pretty. LRO isn't really compatible with packet forwarding, and currently causes the GSO code to crash or warn. I wanted to solve this by disabling forwarding of LRO skbs, but it turns out to be trickier than I thought.
- We wanted to use topology information to allocate one IRQ per CPU package, not per core (or per thread, with HT enabled) for Receive-Side Scaling. Unfortunately this information is only available in some kernel configurations and not for all architectures. I had a go at providing reasonable defaults, but it didn't work too well!
However, this is still only part of my work. My main task at the moment is to write more unit tests for our next NIC.