Adding a new x86 image or related packages to the default x86 image

Elliott Mitchell ehem+openwrt at m5p.com
Mon Nov 13 18:26:04 PST 2023


On Mon, Nov 13, 2023 at 12:48:14PM +0000, Daniel Golle wrote:
> On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote:
> > 
> > How about we follow the approach of Alpine Linux[1] and offer a standard, an extended and a virtual firmware for the x86/64 target?
> > 
> > What packages specifically is another discussion but the approach could be that standard contains all kmods to get network working on all device, extended includes extra LED drivers etc and virtual only contains network drivers for, well, virtual things.
> 
> +1
> I like that much more than adding board-specific images on a platform
> with standardized boot process (such as x86 or armsr).

Are you stating you're planning to modify OpenWRT's boot process to
match the standard way of dealing with that standardized boot process?
Mainly, using a minimal kernel and then using an initial ramdisk to
load device drivers as appropriate to the hardware.

Failing that, I suppose it would be acceptable to have an initial
ramdisk which simply tried to load all modules.  Then it would be
possible to remove unneeded modules later.


The real issue is VMs are unlikely to see devices typically present on
bare metal computers.  Thermal capabilities?  Nope.  Processor frequency
selection?  Nope.  Microcode reloading?  Nope.

Each hypervisor will have a small set of drivers guaranteed to be
present.  These though will be completely different between hypervisors.

I don't know whether it is possible to omit all types of framebuffer from
a Hyper-V VM.  If it isn't possible, then having a framebuffer driver
will be required for Hyper-V, but this consumes somewhere 0.5-1.5MB on
any VM which can omit the framebuffer.

Meanwhile Xen's block device driver isn't even based on SCSI.  As a
result it can completely remove the SCSI subsystem, this saves
another 0.5-1.5MB on a Xen VM.

10MB might not be much for a 2GB VM.  For a 128MB VM, those excess
drivers are a distinct burden.


I've got a WIP patch series for making distinct kernel builds rather
less of a burden.  The series will need some significant testing.


-- 
(\___(\___(\______          --=> 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





More information about the openwrt-devel mailing list