Kernel Hacking

Date: 2002-01-31 22:23:35

Early last week I decided that the best Analog Devices chip for my senior project was an ADSP-2181. A development kit based on an ADSP-2189 was acquired for my use. (This chip has the same base architecture but more memory, which can't be bad.) Someone decided that we should have Monday off for something they called "snow frolic". (Some of the student body headed up to the local ski pseudo-hill and thought that they were having fun. Most of the student body headed off somewhere, taking advantage of the three-day weekend. The rest of us hung out in College Place and slept and worked on long-term projects. Sunday I committed a major Buildmeasite upgrade (the ability for multiple domains to be associated with a single customer) and printed out documentation for the dev kit. Printing documentation was more frustrating than it should have been; I ended up manually duplexing by printing the even pages first, then pushing the pages into the tray pointing in the right direction and printing the odd pages. The major upside is that my stack of paper is half as thick as it would be otherwise. It wouldn't have hurt to have printed only a few of the documents I did print, though.

RTFM'ing resolved enough of my problems that I was able to beat my head against the remaining ones and get "hello world" to compile. But in the process I had to root-canal Elssbett. The development tools run only on Windows (even though the compiler is based on gcc, it's nice to have some good way to download my source to the development board), and require an administrative login to install, which thwarted my attempts to install on any of the local Windows boxen. I borrowed Gem's notebook Elssbett, which has a Windows 98 drive that we occasionally swap in, and installed the tools. I drug Elssbett back to campus with me Sunday night and worked on figuring out what on earth I was supposed to do with the integrated development environment when Elssbett started misbehaving. I paper-clipped her but she continued to misbehave. I eventually concluded that her 2.5" notebook hard drive had detached itself from its connector, which managed to completely thrash its filesystem. Windows was hosed. I root canaled and dubbed the new box Charlemagne Bolivar. (He's Elssbett Mossadim's husband. The Oracle should be able to help you out. Elssbett is now the Linux drive and Charlemagne is the Windows drive.) Tweaking commenced and I managed to get "hello world" running.

Since I was just compiling C code, instead of the 2189's odd assembly language, the thought occurred to me to write and test this code on Ziyal, where I have the full advantages of gcc and gdb and vim. (And plenty of partially-transparent Eterms.) It's all well and good to have code that I think will respond to ARP requests and ICMP echo-request messages, but it's much more fun (and useful) when this code can be tested. The thought occurred to me that it would be most useful to have a kernel driver that piped packets back and forth between the networking subsystem (which would think it was a normal Ethernet device) and a character device to which a userspace program would connect and send Ethernet frames into. This thought wandered around my mind for a few days until this morning, when I pulled my copy of O'Reilly's Linux Device Drivers off my shelf, which included a chapter each on character devices and network devices. I adapted the code on O'Reilly's website (which conveniently is written for kernel 2.4 for the second edition of the book; I have the first, and it's tempting to acquire the second) and ended up with a simple kernel module that does exactly what I wanted.

I was stoked from my kernel hacking ability (which seems to strongly suggest that I'm well on my way to becoming the Alpha Male of Geekdom) and proceeded to test this code. I threw together a tiny userspace test program to double-check the functionality of my code. It dumped address resolution protocol requests just like it was supposed to. I could think of no better IPv4 "hello world" than exchanging ICMP echo-requests and echo-responses. ARP response code was easy, but ICMP proved a tiny bit more difficult.

Ok, so that's an understatement. I couldn't figure out what "16-bit one's complement sums" were supposed to be. (Nothing I tried worked.) I finally convinced myself that I should give up (after three hours of absurdly fun kernel hacking, spread out over the day, and two hours of unsuccessfully beating my head against "16-bit one's complement sums"). I'll hunt down some engineering and computer science professors tomorrow and see if they have any insight into exactly what a "16-bit one's complement sum" is supposed to entail.

The major downside of spending most of the discretionary time from my day doing this is it left little time for the things I really should do by tomorrow. I've now accomplished the things I absolutely should do (which featured an outline (which sucked) and a bibliography (which sucked a little less than the outline) for writing for engineers and reading some Walt Whitman poems (which were graciously shorter than yesterday's epic assignment "Song of Myself") for romantic American literature -- the very same class that another content farmer ranted about earlier) and now I'm thinking about the things that maybe I should do. But I'm writing a changelog instead and thinking about maybe thinking about doing something else.