Future direction of x86 builds

[Elliott Mitchell]

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