A Non-authoritative history of Preemptive Multitasking in the personal computing world.

Back when machines only had one or two CPUs (still the case for embedded devices) the OS Kernel was responsible for making sure that the machine coule process more than one instruction “path” at a time. I started coding back on the Commodore 64, and there it was easy to lock up the machine: just run a program that does nothing. I’d have to look back at the Old Programmer’s Guide, but I am pretty sure that a program had to voluntarily give up the CPU if you wanted any form of multi-tasking.

The alternative is called “preemptive multitasking” where the hardware provides a mechanism that can call a controller function to switch tasks. The task running on the CPU is paused, the state is saved, and the controller function decides what to do next.

Continue reading

ACPI root pointer from UEFI System Table.

As I found out after I posted my lat entry , the correct way to find the Root pointer for the ACPI tables is to get it from the EFI System table. Where does that get set? Here’s the general flow: again, we start at init/main.c. start_kernel.   However, the call is not in the ACPI code, but rather in setup_arch. The call chain goes

start-Kernel->setup_arch->efi_init->efi_get_fdt_params and that seems to pull it our of initial_boot_params. I can’t quite see where that is initialized. Yet. From context it looks like it is constructed out of the kernel command line parameters. Still learning….

Learning ACPI for ARM64 part 1: Finding the Root.

It started as a request from our tech lead: please help triage these patches. So I lookedat the set of patches and started with what looked like the simplest one:

Fix topology for Core scheduling.

It *just* reorders the code to call

notify_cpu_starting() .

Yeah…there is no such thing as a simple patch. These are my notes as I study and learn ACPI. My assumptions are here for all to see, and may well prove to be wrong.

Lets dig in.

Continue reading

Using virt-install and cloud-init

I want to call out a stellar article that told me exactly what I needed to do in order to use virt-install and cloud-init to launch a cloud-image. The only thing I have to add is the caveat that the #cloud-config comment at the top of the user-data file is required. The system will ignore the file if it does not start with that comment. This is the easiest way I know to launch a brand new VM.

XPath for libvirt external snapshop path

The following xmllint XPath query will pull out the name of the backing file for a VM named fedora-server-36 and an external snapshot named fedora-36-post-install,

virsh snapshot-dumpxml fedora-server-36 fedora-server-36-post-install | xmllint --xpath "string(//domainsnapshot/disks/disk[@snapshot='external']/source/@file)" -

The string function extracts the attribute value.

This value can be used in the process of using or deleting the snapshot.

Copy in for-each loops in C++

I had a bug in my OpenGL program. Here was the original code:

  for (Orbitor o : orbitors){

and here was the working version

  for (std::vector<Orbitor>::iterator it = orbitors.begin() ;
       it != orbitors.end();
Continue reading