I'm customizing a Linux kernel.
We all used to do that, of course. Download Slackware or whatever, get it to boot and talk to the hard drive, keyboard, and video card (in some basic mode), then do make config - later, and happily, make menuconfig or even make xconfig - to configure the required device drivers and whatnot.
Nowadays, all the usual distros come with kernels configured for just about anything normal, and with zillions of device drivers in module form. Hurray!
So the last time I went through the kernel configuration process was a dozen or so years ago, when I had to create a sort of micro-distro for an embedded system; at the time, this also involved a custom bootloader, and cross-compiling various utilities (though busybox made life fairly easy on the target-environment front).
That project with the Linux system-on-module developed some new wrinkles this week. Actually, one of them was from a few weeks ago, but I'd been ignoring it, but another, possibly related, issue came up, resulting in /dev/ttyACM0 not behaving at all as expected.
The newer version of the distro for the SOM has its own issues, and I never did manage to get it into a useful configuration. There were aspects of the running version that I couldn't make heads nor tails of. What to do?
Download the correct toolchain, and the kernel sources (TI edition). Apply various patches. Adjust the configuration. Copy stuff onto the MicroSD card containing the not-quite-working system. Boot. And...
After some tinkering, ttyACM0 behaves as it should (and as it does on my workstation). But I neglected to configure the driver for the other (FTDI) serial ports. So, back to the kernel source directory, type a wrong command, and somehow mess things up so that the resulting kernel doesn't finish booting. Oog.
All righty, then: back up a step, via make clean, and try again.
Oops! Now it won't build the .dtb files - device tree blobs, apparently. Gotta have one of those for a proper boot. Has to be the right one, mind.
Now, the kernel source isn't unpacked from a good old fashioned .tar.gz file, oh, no indeed. It's a clone of TI's git repository. That git thing is all the rage these days. I can't just unpack the previously-downloaded archive, but... surely there's some way of using git to restore, from the master repository, whatever files got deleted?
Apparently not. That's a question people have been asking since 2012, if not earlier, and there still doesn't seem to be a good answer, unless you already know what files are missing. WTF?
So now I'm waiting for git to finish creating a fresh clone... which I'll back up to a .tar.gz file before making any changes this time.