Future direction of x86 builds

[Philip Prindeville]

I'm inclined to agree with having two 64 images.  One that's for pizza-box servers like my Supermicro SYS-5018D-FN4T (Xeon D-1548) and one for running in the cloud on hypervisors.

The pizza box images could be built with the common networking chips (i350, i225, x550, etc) and others as 'm' available for download.

For the cloud images all we need are the virtio, ixgbe-vf, igb-vf, and hostdev device drivers.  Ditto for storage, etc.

Don't know if the balloon drivers are actually supported by any cloud providers.




> On Apr 29, 2026, at 10:05 PM, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> 
> The x86 build choices *really* need some attention.  x86 is low-ish
> priority for OpenWRT as most x86 systems aren't constrained to the degree
> OpenWRT's embedded targets are.  Yet at the same time x86 system is
> useful for testing and there are network switches with x86 processor
> inside.
> 
> Presently there are four x86 builds:
> 
> legacy
> geode
> generic
> 64
> 
> There are proposals to get rid of generic (#14944), get rid of geode
> (#22997) and split 64 (#14302).  These *really* need some activity and
> for the requisite decisions to be made.
> 
> I think my original approach for #14944 was wrong.  The choices in
> "generic" are a mixture of very non-generic choices and very generic
> choices.  Of note CONFIG_MPENTIUM4 are the rarest category of 32-bit
> x86 processor.  This will run on most 64-bit processors, but those will
> see far better performance on "64".  Meanwhile hypervisor support and
> EFI support are important for 64-bit platforms, but add large overhead
> on 32-bit platforms.  At this point I think it best to simply delete the
> current "generic".
> 
> I'm unsure of whether or not to merge "legacy" and "geode".  I've read
> Geode processors were being manufactured into 2018.  In fact given how
> old the systems targetted by "legacy" are, I could see simply dropping
> "legacy" and keeping "geode".
> 
> 
> For 64-bit x86 targets there are two questions:  First, should "64" be
> split?  Second, which way should "64" be split?
> 
> I'm unsure of the answer to the first question.  There are two answers to
> the second question though.  The thinking behind #14302 is the extra
> instructions supportted by various processor generations warrant
> specialized subtargets.
> 
> I think instead the various hypervisors may deserve specialized
> subtargets.  In particular I note while x86 computers with 128MB of
> memory are rare, hypervisors allow for VMs of 128MB.  I notice at least
> 10% of the memory of a 128MB VM will be consumed by unusable drivers.
> 
> When it comes down to it, the biggest problem is x86 *needs* dynamically
> loaded kernel modules.  Pass a PCIe ethernet card and PCIe 802.11 card
> into a VM and you've got everything a typical standalone AP has in a VM.
> 
> 
> Perhaps the biggest issue right now is decisions are needed.  Rather a
> lot of mold has built up on x86 and a direction is needed.
> 
> 
> -- 
> (\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
> \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
>  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
> 8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel