On Mon, Nov 13, 2023 at 01:30:10PM +0100, Paul Spooren wrote: > 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.
+1 I like that much more than adding board-specific images on a platform with standardized boot process (such as x86 or armsr). > > Best, > Paul > > [1]: https://alpinelinux.org/downloads/ > > > On Nov 13, 2023, at 03:19, Elliott Mitchell <ehem+open...@m5p.com> wrote: > > > >> 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 > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
