Future direction of x86 builds

[Jeffrey Bosboom]

> Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> So the question is when to merge 32-bit targets together and how to split
> the x86 64-bit target.  I'm in favor of Vm targets.  Someone else had
> been proposing to split 64 based on processor generation.  I do note
> only very early amd64 targets are likely to have PATA hardware.

As a data point, I'm running OpenWRT on a AMD Sempron LE-1100, a single-core x86-64 processor released in 2007, in an MSI MS-7309 motherboard with 1GB of RAM, two gigabit Ethernet PCI cards, and two USB wireless network adapters.  It's fast enough to run CAKE on my bonded VDSL2 connection.  This system won't boot from USB, and I don't want to "waste" a hard drive on a tiny OpenWRT installation, so I'm using the image builder to build bootable ISOs with configuration and booting from a PATA DVD drive.  (This also makes it easy to keep my configuration in version control and allows A/B upgrades by alternating between two DVD-RWs.)  I have an old HP mini-tower computer ready to go when this system dies.

I filed PRs to fix bugs in building the ISO (https://github.com/openwrt/openwrt/pull/21074) and a bug in procd exposed when running off an ISO9660 filesystem (https://github.com/openwrt/procd/pull/26).  As those bugs have been present for a while and there haven't been any me-too comments in the first PR, I may well be the only user running this ISO.

Besides those bugs, figuring out which kmod packages to include in the image was a pain point.  As there's plenty of space on a DVD, I initially included any kmod that wasn't obviously useless to me, but because OpenWRT loads modules eagerly, that didn't finish a boot due to bugs in drivers for hardware I don't have.  I want to have potentially useful modules available in case I need to, e.g., temporarily plug in a USB Ethernet adapter for troubleshooting; on the other hand, including modules I won't use increases my attack surface.  I ended up booting Arch Linux, plugging in whatever USB devices I had handy, and saving the lsmod output.  I couldn't figure out how to automatically turn a list of modules into a list of kmod packages, so I ended up going through all of them, which was tedious.

If we're to support more than one x86-64 target, I think the targets should be based on device driver support, not instruction sets/feature levels.  Of the things a router does, only crypto code comes to mind as benefiting from new instruction sets, and I expect both in-kernel and userspace crypto libraries to use runtime feature detection.  The VM/bare-metal split makes sense to me.

Lazy module loading would definitely make it easier to get started on a random old computer.  On the other hand, whatever udev-like daemon we adopt would be specific to x86 builds and may end up not receiving the necessary maintenance.  There is also the attack surface consideration of having many auto-loadable modules.  One approach might be to automatically load drivers for hardware present at boot, then require the user to manually load modules for any hardware they plug in later.