I know where most of the inspirations for the details of this story come from. Here they are, with my thoughts on what I would do if I were to revise the story. Sorry if I explain some things that are obvious, but not everyone has the same background.
Continue readingPerdido
Written By Adam Young.
This is a short story I wrote my Sophomore year at West Point. It was originally published in “The Circle in the Spiral” the one and only edition of the West Point literary magazine, published in early 1991. Apologies for in anachronisms. More on that later

Error building Kernel ln: target ‘+/source’: No such file or directory
I have battled this problem a couple times and so I am documenting the issue and solution here.
Here is the error message from make modules_install
ln: target '+/source': No such file or directory
Continue reading Make Haste Slowly
In the software development world, we call it technical debt.
In the Army it was “Half-assed, full-blast. Don’t know where we are going but we should have been there yesterday.”
Finding a line of code in the Kernel from a stack trace
To find out what line a particular stack trace entry points to, use the script ./scripts/faddr2line for example If I have the line __get_vm_area_node+0x17c/0x1a8 I can run
./scripts/faddr2line vmlinux.o __get_vm_area_node+0x17c/0x1a8
__get_vm_area_node+0x17c/0x1a8:
__get_vm_area_node at /root/linux/mm/vmalloc.c:2579 (discriminator 1)
Following a code path in the Linux Kernel without a debugger
Sometimes you don’t get to use a debugger. When do bare metal development, often it is faster to get to the root of a problem by throwing in trace statements, and seeing what path is taken through the code.
Continue readingHow to optimize a flipit solve
According to the puzzles coder, any puzzle can be solved in 3 clicks (or less). That means that following my algorithm is likely to be significantly less efficient than an optimum solve.
I am not sure I buy it…yet.
Lets see if we can optimize a solve path for a puzzle.
How to Win at Flip It
My Friend Evan Barr coded up a puzzle he had read about in a Mensa magazine. I suggest you click around on it a bit before reading on.
Building a Kernel RPM with the Built-in Makefile target
Note that you need to have a .config file that will be included in the build. It will also use the Version as specified in your Makefile. Then run
make rpm-pkg
Which will use the RPM build infra set up for your user to put the rpm in $HOME/rpmbuild/
Edit: Note that a bunch of dependencies are needed to get the Kernel to build. If you run the above command and it fails out with a message that you are missing a dependency, you can use this pair of commands to get the yum-build dep tool installed, and use that to install the dependencies as listed by the generated kernel.spec file.
wget https://src.fedoraproject.org/rpms/kernel/raw/rawhide/f/kernel.spec
yum install dnf-utils
yum-builddep ./kernel.spec
Faking a device via ACPI
I need to write a driver for a device that does not exist yet. So, I am going to use the Linux kernel tooling fro ACPI to create the illusion that the device exists. Here is how.
Devices on an ACPI enabled Linux machine typically exist in a able called the DSDT. This has a real name, but I just thing of it as “Different Stuff Different Table”. However, you can also have a machine specific table that you create at boot time and put entries in there. This is called the SSDT. Again, it has a real name, but I just think of it as “Same Device Different Table” Here is my simple SSDT definition in the ACPI domain specific language.
/*
* Template for [SSDT] ACPI Table (AML byte code table)
*/
DefinitionBlock("","SSDT", 2, "Ampere", "_SSDT_01", 0x00000001)
{
Scope(\_SB)
{
Device(MCTP)
{
Name (_HID, "MCTPA1B2")
Name (_STA, 0x0F)
}
Device(PLDM)
{
Name (_HID, "PLDMA1B2")
Name (_STA, 0x0F)
}
Device(PSTL)
{
Name (_HID, "POSTA1B2")
Name (_STA, 0x0F)
}
}
}
Now, this actually has three devices in it, and I was doing some unit testing setup with dependent devices so I though I might use the other ones. I left them in as an example to show how multiple devices look in an SSDT.
To convert this to the binary format, I use iasl, a utility in the acpica-tools RPM. Yes, I still do RPM, although all of this works on Debian based systems as well.
Here is my script to load it into the Linux kernel. It uses a module for the ACPI configuration filesystem.
#! /bin/sh
modprobe acpi_configfs
mkdir /sys/kernel/config/acpi/table/ssdd
cat ~/acpi/bak/mctpdev.aml > /sys/kernel/config/acpi/table/ssdd/aml
To confirm that the file exists, you can use the acpidump command. If you run it with the -b flag you get all the tables in binary format.
[root@hackery tmp]# mkdir acpi
[root@hackery tmp]# cd acpi/
[root@hackery acpi]# acpidump -b
The iasl command will then decompile the table and you can view the contents. I’ll leave you with the full content.
[root@hackery acpi]# iasl ssdt.dat
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20220331
Copyright (c) 2000 - 2022 Intel Corporation
File appears to be binary: found 31 non-ASCII characters, disassembling
Binary file appears to be a valid ACPI table, disassembling
Input file ssdt.dat, Length 0x83 (131) bytes
ACPI: SSDT 0x0000000000000000 000083 (v02 Ampere _SSDT_01 00000001 INTL 20220331)
Pass 1 parse of [SSDT]
Pass 2 parse of [SSDT]
Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions)
Parsing completed
Disassembly completed
ASL Output: ssdt.dsl - 1141 bytes
[root@hackery acpi]# cat ssdt.dsl
/*
* Intel ACPI Component Architecture
* AML/ASL+ Disassembler version 20220331 (64-bit version)
* Copyright (c) 2000 - 2022 Intel Corporation
*
* Disassembling to symbolic ASL+ operators
*
* Disassembly of ssdt.dat, Sat Jul 8 04:42:31 2023
*
* Original Table Header:
* Signature "SSDT"
* Length 0x00000083 (131)
* Revision 0x02
* Checksum 0xCE
* OEM ID "Ampere"
* OEM Table ID "_SSDT_01"
* OEM Revision 0x00000001 (1)
* Compiler ID "INTL"
* Compiler Version 0x20220331 (539099953)
*/
DefinitionBlock ("", "SSDT", 2, "Ampere", "_SSDT_01", 0x00000001)
{
Scope (\_SB)
{
Device (MCTP)
{
Name (_HID, "MCTPA1B2") // _HID: Hardware ID
Name (_STA, 0x0F) // _STA: Status
}
Device (PLDM)
{
Name (_HID, "PLDMA1B2") // _HID: Hardware ID
Name (_STA, 0x0F) // _STA: Status
}
Device (PSTL)
{
Name (_HID, "POSTA1B2") // _HID: Hardware ID
Name (_STA, 0x0F) // _STA: Status
}
}
}