Objective of OpenWRT/x86?

Thu May 4 18:43:08 PDT 2023

On Thu, May 4, 2023 at 7:35 AM Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> On Thu, May 04, 2023 at 03:50:05AM +0100, Daniel Golle wrote:
> > On Wed, May 03, 2023 at 06:36:10PM -0700, Elliott Mitchell wrote:
> > > On Tue, May 02, 2023 at 02:45:43AM +0200, Alberto Bursi wrote:
> > > > On 26/04/23 22:17, Elliott Mitchell wrote:

> Something is very wrong here.
>
> Question is whether it is deliberate versus accidental.
>
> One possibility is you last looked at an OpenWRT x86 5.10 kernel and
> figured the number would be roughly in line with 5.15.  In this case
> there was a rather drastic increase in size between 5.10 and 5.15 for
> x86.
>
> Another possibility which comes to mind is that is pretty close to the
> x86 5.15 compressed image size.  I would expect you to be aware modern
> data compression algorithms are fairly effective and can often provide
> substantial reductions.  I suppose you could be unaware of this, but
> given how well known this is I would be left suspecting deliberate
> distortion.
>
> The last generic OpenWRT x86 5.15 image I built less than a week ago
> produced a roughly 28MB vmlinux.bin file.  Some of that disappears since
> initialization portions will be freed after boot, but this is fairly
> representative of runtime use (additional will be used for what is found
> during boot).
>
> My most recent OpenWRT based image which was moderately adapted to a
> specific target (running in a Xen VM) was 18MB.  *That* is substantial
> enough to go after.

Here are memory figures for a fully initialized OpenWrt x86/64 QEMU
systems. Very easy for anyone capable of proposing kernel
configuration patches to try themselves.

$ qemu-system-x86_64 -nodefaults -smp 2 -m 128 -vga std -nic
user,model=virtio -nic user,model=virtio -drive
file=openwrt.img,format=raw,if=virtio
# opkg update && opkg install luci && reboot

https://downloads.openwrt.org/releases/22.03.5/targets/x86/64/openwrt-22.03.5-x86-64-generic-ext4-combined.img.gz
Kernel: 5.10.176
/boot/vmlinuz size: 5.0M
Memory used after boot settles: ~44M

https://downloads.openwrt.org/snapshots/targets/x86/64/openwrt-x86-64-generic-ext4-combined.img.gz
Kernel: 5.15.110
/boot/vmlinuz size: 5.6M
Memory used after boot settles: ~46M
(Caveat: snapshot build)

> Is OpenWRT/x86 a networking device Linux distribution?
> Yet again, I'm asking the question:  What is THE goal of OpenWRT/86?

> Is OpenWRT/x86 aiming to be a desktop Linux distribution?

No, but everything else is as modular as possible through packages etc
so people can do whatever they want with it. Even routing packets.
Good container support will mean the OpenWrt distribution itself won't
ever need to grow into something like Debian and can stay focused on
embedded/networking use cases.

>From https://openwrt.org/ :

> The OpenWrt Project is a Linux operating system targeting embedded devices. Instead of trying to create a single, static firmware, OpenWrt provides a fully writable filesystem with package management. This frees you from the application selection and configuration provided by the vendor and allows you to customize the device through the use of packages to suit any application. For developers, OpenWrt is the framework to build an application without having to build a complete firmware around it; for users this means the ability for full customization, to use the device in ways never envisioned

> Is OpenWRT/x86 a developer test simulator for "real" OpenWRT targets?

It is a real target that people and companies use daily for their
packet routing needs. Also, the best test target would be... a real
target.

> Is OpenWRT/x86 a networking device Linux distribution?

More or less I'd say. OpenWRT/x86 is just a build of OpenWrt that runs
on x86. so it's mainly focused on providing a good out-of-the-box
network router. Plug in NICs and they just show up. It just so happens
that the x86 platform/ecosystem has more diverse boot-related hardware
than specific isolated targets, which will make the kernels a little
bigger than other focused targets. You can choose to use a serial
console, or choose to use a VGA console. It simply works
out-of-the-box in a few minutes on most x86 hardware or x86 VMs.
Wonderful.

I'd say this is the single most important feature of the x86 target,
that it just works out of the box. Its now 2023. No-one has time to be
recompiling kernels when they just need a reliable router now while
juggling work and family. If you handed over a work-critical
networking appliance with hand-rolled kernels to your work colleagues
to maintain, you might as well have handed them a barnfire. So its
good the x86 targets just work without any messing due to being too
lean.

---

The original issue raised in these threads is centered around the
perception that the default build/install of the x86 targets have
excessive memory usage in different scenarious, along with various
patches and suggestions for cutting this down. However simple testing
like above shows this isn't really a problem.

> 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.
>
> 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).

By your own standards, the current x86 builds as shown above already
meet the "relatively small" requirements. Great :)

> KVM/Qemu, Hyper-V and Xen are likely the bigger gains.  My impression is
> the Virtio stuff is fairly encompassing and thus a drag on others.  While
> Hyper-V is pretty complex and also a major drag on others.  Meanwhile Xen
> is very small and thus gets dragged down by others.

Maybe there is a case for a separate all-in-one virt profile if it
fills up with exotic things, but as others have said IMHO its nicer to
stay with a flexible "run-everywhere" image, unless there is a very
clear reason not to. I'm sure no-one would mind some more virt storage
drivers in the current x86/64 builds, but something like Xen might
only be possible with a separate kernel/target.

Anyway, this is going around in circles, so I'll leave my input there.