Sometimes you want to build a single module for an existing kernel but you don’t want to recompile the whole thing. Here’s a way to save some time and compile only the code you care about.
I had some fun decoding hexidecimal stings and learned a few things in the process.
There are several ways to capture kernel log output on a remote machine. One way is to configure the kernel to use a serial port as console. If you have a machine that has a serial port, or you’re running a VM, this method can be very helpful in capturing kernel log data when a panic occurs.
Related to the earlier article on kernel development, here’s one thing that I find very useful. During development I often compile, load, unload, modify, and recompile in a loop. I rarely do this on my development machine but rather in a VM or on a nearby test machine. It’s a pain to keep typing
dmesgall the time. So I keep a separate terminal open with
dmesgrunning in a loop. Actually it’s a split pain within Tmux, but that’s not important yet. Here’s what I do.
My intent with this, and related articles to come, is to explain how I develop software that runs as part of the Linux kernel. Not so much the way my code works, but rather the tools, configuration, and techniques that allow me to create kernel code quickly (within reason).
Vim has a makeprg setting that can be more helpful than you might imagine. Here are a few ways to take advantage of it.
I recently needed to call the
cpuidinstruction from some C++ code. This is well documented on wikipedia and everything went fine until I hit a snag moving the code from x86_64 to i386.
subscribe via RSS