Objective of OpenWRT/x86?

[Stefan Lippers-Hollmann]

Hi

On 2023-05-03, 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:  
[...]
> > Then there is the virtualized drivers that were just added to the kernel 
> > and not properly modulized, maybe it was easier like that, don't know.  
> 
> These two are the same issue.  Not including the drivers for a hypervisor
> could make the image not boot on that hypervisor.  Though most
> hypervisors will include some fallback device emulation which provides
> inferior performance.
> 
> > Because on x86_64 storage and RAM is measured in Gigabytes so saving a 
> > few hundred kilobytes by removing the "all hardware just works with a 
> > single image" feature is NOT a worthy tradeoff.  
> 
> Partially true, partially untrue.  Saving a few hundred kilobytes isn't
> worthwhile.  Shrinking the kernel by 35% and userspace by 20% though IS
> worthwhile.
> 
> Notably I'm making use of Xen.  The Xen devices don't try to look like
> normal hardware.  As a result the Xen block devices don't depend on the
> SCSI subsystem.  Then you completely disable all emulated graphics
> devices (simulated serial consoles work fine) and things have shrunk
> drastically.
[...]

And combining these two statements, you're in a catch-22 dilemma...
If you optimize the kernel configuration for Xen-only, it will no longer
boot on qemu-kvm, hyper-v, virtualbox, vmware. Once you resurrect support
for all of those, your high-density virtualization goals go out of the
window - and the gap to support for real hardware becomes negligible, 
especially once you add in support for IOMMU/ DMAR based PCI pass-through
support (which was already mentioned to pass through wireless cards).

> I'm concerned at the large number of things enabled in the kernel
> configurations.  Traditionally OpenWRT has used f2fs, yet x86 also has
> ext4.  With the percentage of systems using SSDs, would seem advantageous
> to stick with that flash-friendly choice.
[...]

f2fs && ext4 is a bad example here, on the one hand for the reasons Daniel
Golle has already raised (the selection between f2fs and ext4 being based
on the overlay size at firstboot time), on the other hand because we are 
only talking about a few KB in this case (and f2fs is a horrible 
filesystem, huge overhead (way more than half of those 100 MB given as 
deciding factor), bad fsck options, bad (online-)resize behaviour, so 
killing f2fs with fire would be the more sensible approach - not forgetting
that dropping ext4 support would kill the ext4 based images, which are very
popular among x86 and ARM SBC (RPi, sunxi, rockchip) users).


> Many desktops can use a serial port as console (universal on servers).
> Hypervisors generally provide some flavor of serial port-like device
> (often they misbehave by doing rather more than 115.2kbps).

Serial console ports (in the sense of rs-232c) on consumer desktops became 
extinct around sandy-bridge times, consumer notebooks haven't had them for 
over two decades by now. Yes, in some cases you will find a non-standard
onboard header for them, but even that isn't a given. Yes, I'm aware that
business computers are more likely to sport serial consoles (even today)
and that dedicated x86_64 routing platforms and rack servers are very 
likely to have them, but those aren't the only (very common-) x86 system.
None of your consumer (desktop-) mainboards/ system will, none of your
notebooks will either - and it takes two to tango (admitted, the client
side may go with USB2serial adapters, but the host side won't be able to).

There may be optimization potential for 32 bit x86, in the sense of 
covering generic, geode and legacy in one image - as all of these are
obsolete hardware, with little gains by different ISA optimizations.

There is definitively potential to merge UEFI and legacy-CSM images into
one for x86_64, but I don't really see any reason to drop hardware support
for x86_64/generic. If you really wanted to provide high-density demands,
you'd end up with at least five (kvm, Xen, hyper-v, virtualbox, vmware, 
parallels, maybe more) new images next to x86_64/generic, which I don't 
think anyone really wants or needs (those who do, will want even more
fine-tuned images, and x32 may be part of those considerations). And no,
I'm not advocating for this, at all.

Regards
	Stefan Lippers-Hollmann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20230504/09379bd0/attachment.sig>