Future direction of x86 builds

[Elliott Mitchell]

On Thu, Apr 30, 2026 at 04:34:30PM -0400, Michael Richardson wrote:
> 
> 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.
> 
> 1. I think that you are right to think about dropping generic.
> 
> 2. I know that geode CPUs were used widely in "stuff" until 6-8 years ago.
>    I don't know if that is worth keeping.  I would treat it as some other
>    CPU/arch, and consider it like one might consider some 2016 era ASUS.
>    So, if there is someone who wants to maintain it...
> 
> 3. I agree with you that a *virtio* image is super-useful for testing.
>    (I *also* use one to test virtualized images of an entirely different embedded
>    system.  I need to make sure it works *with* OpenWRT in a variety of
>    configurations...)
>    I don't think that this needs much in the way of kernel modules.
>    Compiling everything in might be a win when testing.
>    Call it virtioAmd64 or something like that.
> 
> 4. I think that the case of an amd64 image that has a *real* PCIe ethernet card
>    and/or PCIe 802.11 card passed in, suitable for someone who has some
>    "small" {by 2026 desktop standards} box hosting all sorts of stuff is
>    yet another *different* situation.
>    Yes, it needs lots of possible kernel modules, maybe bunches of USB
>    modules too.     I would give this a different name; I don't know what.
>    "guest64" or something like that.
> 
> 
> So to me, #3 is a group need, and I have no problem if it's amd64 only.

The current "64" configuration matches this.  I do note virtio is mostly
about performance.  Enough x86 hardware can be emulated in better than
real-time that virtio shouldn't strictly be an absolute requirement.

> #2 and #4 should depend upon someone who wants to maintain it.
> #2 is 32-bit, so really has nothing in common with the rest.

There is a vote for merging "geode" into "legacy":
https://github.com/openwrt/openwrt/pull/22997

I'm presently unsure whether or not it should be merged in.  I'm
sympathetic to not merging as they were in production less than a decade
ago.  Yet at the same time all Linux 32-bit platform support is slowly
degrading.

> #4 could be 32-bit or amd64.  32-bit VM guest systems used to use their ram
> better, and that mattered a decade ago when many small-office users were
> using recycled hosts that were 4-8 years older.  Today....

Right now the best combination would be an amd64 kernel with userspace
using the x32 ABI (https://wiki.debian.org/X32Port
https://en.wikipedia.org/wiki/X32_ABI).  The additional and larger
registers are highly valuable.

>     > 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.
> 
> That's okay.  A long time ago (2008) I used *a lot* of tiny VMs as routers as
> part of a virtual desktop infrastructure, and having them small was more
> important.   I remember we couldn't make RHEL even install with less than 1GB
> (yum!), but I can't recall if we settled for OpenWRT or Debian. Company died soon.
> 
>     > 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.
> 
> :-)

The trend is 32-bit platforms are disappearing.  Older, slower targets
are good targets for OpenWRT as there are similarities to embedded
targets.  Yet if all 32-bit target support is removed from the Linux
kernel OpenWRT's situation will be interesting.  I don't expect ARM32 or
MIPS32 to disappear soon, but the writing is on the wall.

The real news is:
https://www.phoronix.com/news/Linux-7.1-VFS-Kino-32-bit
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b2600f81cefcdfcda58d50df7be8fd48ada8ce2

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.


-- 
(\___(\___(\______          --=> 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