Objective of OpenWRT/x86?

[Joseph Mullally]

One nice feature for users of the "x86/64" and similar builds are that
they work out of the box on most generic hardware or virtualization
platforms. I use it on real hardware and KVM with device passthrough,
and it was very easy to set up. I'm guessing this is far more common
than speculative high density VM deployments.

It makes more sense to make a new lightweight VM profile rather than
chopping stuff out of the generic ones.

But is one needed, and how much memory would be saved? Have you
actually tried running the "x86/64" image with 128MB ram under QEMU?
Default 22.03.4 install shows 45MB used. With "wpad-openssl" and
"kmod-mac80211-hwsim", its up to 53MB. These requirements rise
depending on load. I'm guessing those memory figures in the wiki docs
are just arbitrary, showing people they can run cool stuff.

If memory usage optimization is the goal, I suggest these discussions
and patches be tested and informed by real measurements in that area,
to discuss whether the tradeoffs with compatability are worth it.

- Joe

On Wed, Apr 26, 2023 at 9:19 PM Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
>
> Well, was a specific objective ever chosen for the x86 version of
> OpenWRT?
>
> I can state my goal/hope for OpenWRT/x86.  The *WRT Linux distributions
> were so named for originally targeting the LinkSys WRT54G.  This was a
> small AP, so one might expect builds to be for small APs.  By today's
> standards 128MB RAM and 16MB of storage is relatively small.
>
> Since this network is in the moving towards the server phase, the AP drew
> my attention.  Turns out all of the hardware of an AP is available for
> servers, though in distinct form-factors.  If the server has a full
> IOMMU, the hardware can be directed to a VM and you have a proper AP in a
> VM.
>
> Problem is instead of the recommended 128MB memory, 16MB of storage
> (https://openwrt.org/supported_devices/432_warning) the virtualization
> examples (https://openwrt.org/docs/guide-user/virtualization/start) are
> suggesting massively more memory.  256MB (small Xen example), 512MB
> (VMware OpenWRT/15.05) or 1GB (Qemu examples).
>
>
> I don't yet have a full handle on the issues.  My first thought was the
> large sizes come from early stage development and not wanting to bother
> with memory limitations.  Another possibility is this comes from simply a
> thought pattern of "x86 memory is cheap, just throw memory at it".
>
> Yet if one is wanting to use this for serious purposes, memory IS a
> concern.  GCC is pretty capable for x86, a quick check suggests GCC tends
> to produce binaries for x86 which are four-fifths the size of those for
> ARM.  Yet everything for OpenWRT/x86 is suggesting at least *double* the
> memory?!
>
>
> One issue I've found is the kernel configurations seem ill-suited to x86.
> Almost any storage driver used by 10 or more people is built into the
> kernel.  As a result the *single* kernel is huge.
>
> The conventional approach for x86 is to use an initial ramdisk and build
> everything as modules.  Issue here is OpenWRT doesn't currently have the
> scripting/tools for runtime probing of a storage subsystem.  I think this
> is a fine approach if the committers are up for all the change this will
> entail.
>
> Alternatively x86 could be broken into more builds.  This would emulate
> how OpenWRT works for all other devices.  "generic" would likely be 2-3
> distinct builds.  "64" would be 4-6 distinct builds.  Issue here is how
> many distinct builds should be created?
>
> If one was to go this direction, I suppose there might be "giant" or
> "desktop" build.  Each hypervisor could use a target, include "hardware"
> guaranteed to be present.  Then build all network drivers as modules (so
> any device can be passed-in).
>
>
>
> Examples of things which don't seem to fit well are CONFIG_AGP and
> CONFIG_DRM.  I would expect those for a desktop Linux distribution due
> to GUI.  For OpenWRT which tends towards networking/embedded those seem
> out of place.  CONFIG_FB is similar, though some devices do have actual
> limited frame-buffers.
>
> Another item is the goal of trying to self-host.  Being able to self-host
> is a worthy goal, but that has very distinct needs from an embedded
> networking device.
>
>
> --
> (\___(\___(\______          --=> 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