OpenWrt Next Generation Ideas

[Elliott Mitchell]

On Fri, Mar 31, 2023 at 02:47:23PM +0100, Daniel Golle wrote:
> 
> Another example is selection of the rootfs. Kernel folks argue that
> we should use an initramfs for that, however, we try to avoid the
> overhead of using an initramfs with it's own userland just for that.

There are two options here.  First, 10 mildly different images can be
built for each of the 10 variants of hardware.  Second, 1 image can be
built which loads appropriate drivers during boot.

Issue is OpenWRT aims for the first option for ARM/MIPS/RISC-V.  For x86
though there are 2 candidate images to cover all configurations, which
for the first approach should have 7-12 images.

x86 has the "generic" image and the "64" image.  For the first approach
there should be a different build for:

1> Running on raw hardware.

2> Running on HyperV.

3> Running on KVM.

4> Running on QEMU.

5> Running on Xen.

So should OpenWRT's x86 builds be distinct from ARM/MIPS/RISC-V in using
an initramfs in order to combine these?  Should OpenWRT have 12 distinct
x86 images?

Both approaches are nominally viable, problem is *one* approach needs to
be chosen for x86 on modern hardware.


On Fri, Mar 31, 2023 at 03:52:47PM +0300, Arınç ÜNAL wrote:
> On 31.03.2023 14:33, Daniel Golle wrote:
> > 
> > On Fri, Mar 31, 2023 at 12:44:12PM +0300, Arınç ÜNAL wrote:
> >>
> >> Some Modest Virtualization Observations
> > 
> > How is this related? Virtualization (with OpenWrt being the guest)
> > matters on x86 which is usually not that space-constraint.
> > And maybe armvirt. If space is a problem for older x86 boards, let's
> > disable guest support in x86/legacy.
> 
> It was a broad example without any explanation. What caught my attention 
> there is the configuration of the kernel that causes problems, if I 
> understand correctly.

The real issue is everything I've looked at makes it seem x86 hasn't
received the attention it needs.  Looks like it is purely a development
tool, not really providing the functionality it could.

Notable kernel options:
# CONFIG_XEN_BACKEND is not set
Most Xen backend drivers aren't well suited for OpenWRT, but the
ethernet backend is.

# CONFIG_CFG80211 is not set
# CONFIG_LIB80211 is not set
If 802.11 devices could be fully passed into a VM you could have a
proper access point in a VM.


Then we have the architectures chosen.  "64" => x86_64-linux-musl,
"generic" => i386-linux-musl/Pentium4

Could be CONFIG_MPENTIUM4 merely uses options ideal for a P4 and could be
reasonable for most of AMD's 64-bit processors, but otherwise that is
about as non-generic as possible.

Having done a bit more looking recently, could be "generic" should point
at x86_64-linux-muslx32, not x86_64-linux-musl.  (x32 is running ILP32 on
an amd64 processor)


All of the suggested VM setups are massively larger than any other
OpenWRT supported device.  The smallest was the Xen setup which merely
suggested 256MB of memory.


Should also be noted, some higher-end ARM boards have enough hardware
to potentially be worth having an OpenWRT AP in a VM.

The bottom line is, except for the Geode support, all of the x86
configurations looked like purely meant as development tools.  Whereas
with modern hardware it is entirely reasonable to have a proper OpenWRT
AP in a VM.


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