I do not work with AI tools. This is not advice from experience of working with AI. It is advice from working with access controls in general.
Any agent has responsibility and authority. Responsibility is what it is required to produce. Authority is the set of resources that you provide to that agent. This does not change if the agent is human or automatation, and AI agents fall in to that later category.
I find myself writing a program in C that is supposed to handle multiple protocols. At its entry point, the protocol is Platform Communication Channel (extended memory, type 3 and type 4). Embedded in that is an Management Component Transport Protocol (MCTP) message, and embedded in that is one of many different protocols.
I might want to swap out the PCC layer in the future for….something else. MCTP can come over many different protocols, so there is a good be that the tool will be more useful if it can assume that the protocol outside of the MCTP layer is something other than MCTP.
One problem I have is that the MCTP header does not have a length field. We do not not know how long the payload is; all it has is version, source, destination, and flags. Thus, if we want to pass a buffer of type MCTP header along, and we want the length, we need to pass it in a separate field. This goes both for incoming (how many bytes to read) and outgoing (how many bytes to write).
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 readingMy defaults are set for Linux Kernel development, but I have been in Qemu land lately and these values make it easier to format.
set shiftwidth=4
set expandtab
set tabstop=4
retab
Using ebpf and the bpftrace command line utility, you can perform simple reporting on function calls. Here’s an example:
Continue readingI have an application that I want to share with my team. Fortunately, we have a shared server, so it is pretty easy to do so: if I put a file in /usr/local/bin it can A) be executed by anyone on the server and B) will not interfere with RPM packages. But, I do potentially want to put this code on other machines as well, so I am going to buld it as a pip package, upload it to a team repo (apache HTTPD instance on this machine) and then install it from pip as root.
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())}'