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

[Elliott Mitchell]

> 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