When debugging Qemu, it might be helpoful to instrument Linux Kernel to see when interrupts get received, or see data on the other side of a transfer. If you have to modify the Kernel on a regular basis, it can be faster to build it in place than to build a customer RPM/DEB and install inside the VM. Here is how I have been going about updating the kernel.
Continue readingThe Qemu implementation uses a Flattened Device Tree (FTD) to manage the virtual implementation of the physical devices in a machine. I need to create a FTD entry for the MCTP-PCC implementation I am writing in Qemu. Since this is new to me, and I am working (as I most often do) via Ttrial and error, I want to see the FTD entry after I write it. Here is how I am dumping it.
Continue readingWhen developing Linux Kernel code, I have found myself wanting to have a test fixture inside the Firmware that lets me inspect the values communicated out of and into the Linux Kernel. I am currently writing one such fixture in Qemu. And I have an interrupt that is not getting handled by the Linux Kernel, I think because it is not getting delivered.
I have found it quite valuable to run this Qemu process in the Gnu Debugger. Here is how I (with help) got to the bottom of the mystery.
Continue readingUsing ebpf and the bpftrace command line utility, you can perform simple reporting on function calls. Here’s an example:
Continue readingWhile it is tempting to use printk or pr_info when coding in order to trace function in the Linux kernel calls, it turns out that there os a; ready a utility to simplify that. Here are the steps I used to enable ftrace for mcpt-pcc and figuring out where a function call stack ended (in the middle of a debugging session where I had broken it)
Continue readingThe following command will print a stack trace whenever pcc_send_data is called.
sudo bpftrace -e 'f:pcc_send_data{print(kstack())}'Software Development flow is an elusive beast, easily frightened away. The easiest way to lose the flow is to have a long development cycle. Building the entire Linux Kernel takes time. If you are developing a single driver that can be built as a stand alone module, you do not want to have to rebuild the entire Kernel each time you make a change to that module. If that module crashes the machine when it runs into an error, you do not want to have to wait for that machine to reboot before digging in to the debugging process.
These two guidelines lead to a pattern of building on one machine and deploying on another. Here is one way to go about this process.
We regularly sync various git repos from upstream to our company speicfic Linux repository. However, sometimes when working on a development machine, I need a branch from stable that we have not synced yet. If I did a blobless clone from our repository, doing a fetch from stable is going to pull over lots of blobs that I do not need.
Instead, I want to fetch just a specific tag. I can do this by adding the tag to the fetch command, and it will pull over only those blobs
Cloning the Linux Kernel repository takes time. We don’t need every commit ever for our work. But we do need multiple branches. Here are some numbers for how long it takes to do various operations.
Continue readingIt took me a couple months to get back to my patch, and in the interim, I forgot everything about formatting a patch series to LKML. Here’s what I have remembered.
Continue reading