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+sig...@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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel