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

[Paul Spooren]

Hi all,

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.

Best,
Paul

[1]: https://alpinelinux.org/downloads/

> On Nov 13, 2023, at 03:19, Elliott Mitchell <ehem+openwrt at m5p.com> wrote:
> 
>> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann <s.l-h at gmx.de> wrote:
>> 
>> On 2023-09-14, Paul Spooren wrote:
>>> 
>>> I’d like to merge the PR which adds the Mellanox Spectrum SN2100 to 
>>> OpenWrt[1]. In its current state a new x86 image would be added next 
>>> to the generic x86 image. Another approach is to add all related 
>>> packages to the default image. Either way creates a working image.
>>> 
>>> I remember that people were complaining about a “bloated” x86 image 
>>> which slows down their container/VM needs. So what would be a simple 
>>> way forward here?
>> [...]
>> 
>> If at all reasonably possible (assuming the size increase is roughly in
>> the ball park  of 1-2 MB for the total image), I'd suggest to stick to a 
>> single x86_64 image for maintenance and testing reasons alone. The bump
>> of the x86 targets to kernel v6.1 -while easy- is mostly stalled due to
>> there being three 32 bit x86 sub-targets and the need to go through the
>> kernel config rebase three times, which is wearing thin the patience and 
>> motivation of doing so (x86_64 alone would have been ready >2 months 
>> ago). Unless these SN2100 devices suddenly become a cheap commodity and 
>> ubiquitous among OpenWrt developers and -users, I fear that it would 
>> just add to this churn and pretty much rot away in the tree, while at 
>> the same time making progress harder for the other x86{,_64} devices.
> 
> In that case I would suggest removing the x86/generic target.  Since it
> has CONFIG_MPENTIUM4=y, that is only appropriate for a very small number
> of computers.  The earlier ones are covered by x86/legacy, the later ones
> are covered by x86/64.
> 
> I don't know what others are running into, but the bigger issue for VMs
> (possibly containers as well) is memory is expensive.  A small VM
> machine could have 2GB of memory.  OpenWRT's baseline of 128MB is quite
> nice for sticking a full-featured AP in a VM.
> 
> 
> On Sun, Nov 12, 2023 at 06:31:29PM -0700, Philip Prindeville wrote:
>> 
>> Sometime back I tried to add "pcituils" and "usbutils" to the generic x86_64 image, and was told that they weren't sufficiently "ubiquitous" to add to the default image.
>> 
>> I note that they can be removed from the BOM easily by doing:
>> 
>> DEVICE_PACKAGES += -pciutils -usbutils
>> 
>> And that would remove them if they were already present in $(DEVICE_PACKAGES).
>> 
>> I've never encountered an x86_64 platform that didn't have both USB and PCI, as they've without question become a "cheap commodity".
>> 
>> Contrarily, I've yet to own or operate a platform that has a Mellanox switch.  This seems arbitrary.
>> 
> 
> I've encountered plenty of amd64 devices which lacked USB, PCI, PATA,
> SATA, SCSI and SAS.  They're all VMs, yet they're quite functional (an AP
> in VM will almost certainly need PCI).
> 
> I think the various hypervisors could do with targeted builds.  Mostly
> this involves removing nearly all common drivers, then keeping/adding a
> small number of specialized drivers.
> 
> 
> -- 
> (\___(\___(\______          --=> 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
> 
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel