Objective of OpenWRT/x86?

[Elliott Mitchell]

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