> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann <s....@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+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
