Re: Adding a new x86 image or related packages to the default x86 image
On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote: > On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > > > > Each hypervisor will have a small set of drivers guaranteed to be > > present. These though will be completely different between hypervisors. > > Do you really think having just the (partially shared) drivers for 3 > hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too > much? Those drivers are very tiny... Hopefully I can revise my opinion here. Issue is some hypervisor drivers are small, some are not. I could see having two hypervisor kernel builds. One featuring only the smaller drivers, one featuring the jumbo drivers. I note Virtio-block is fairly small. It operates on top of the block layer and shouldn't require too much extra. The Fusion MPT driver, which VMware requires is a big driver. Not only is the driver itself large, but it then plugs into the SCSI layer which itself is quite substantial. This could be as much as 2-3MB total. This is enough not to want built-in for a kernel meant for other hypervisors. I'm totally unfamiliar with Hyper-V, aside from knowing which company is behind it. I do find the idea of using OpenWRT in a VM on Hyper-V as one's border firewall entertaining. :-) I suspect Hyper-V may require ACPI support, in particular I suspect its virtual network and block interfaces are provided by ACPI table. I'm unsure exactly how much overhead that is, but I suspect it is enough to want a separate kernel (or everything in modules). Additionally Hyper-V may insist upon a graphical console and USB. Both Virtio-SCSI and Xen-pvSCSI rely on the SCSI layer, which is relatively large. Yet those hypervisors have block layer drivers which are rather smaller. So, there might need to be a few distinct kernels for hypervisors, or perhaps an awful lot as initrd modules (enough to load the block drivers for all hypervisors). In case you haven't guessed, all patches I'm posting are headed in the general direction of trying for a slimmer VM kernel build. I'm trying to get CONFIG_HW_RANDOM_GEODE into the Geode build, since it presently leaks into the "64" build and the "64" build would be the obvious basis for a hypervisor kernel. Similar situation for CONFIG_SCx200. I've got some initial patches for a slim VM kernel configuration, but right now things are still at the pre-split cleanup phase. CONFIG_X86_INTEL_LPSS=n seems unlikely for the present "64" configuration, but will be appropriate for a VM kernel. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include 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
Re: Adding a new x86 image or related packages to the default x86 image
On 11/13/23 21:49, Daniel Golle wrote: On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote: Paul Spooren [2023-11-13 13:30:10]: Hi, 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? FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead recommend to fix that mlx firmware package and call it a day? Thanks for pointing this out, increasing the default image by 1.6MiB is bearable on x86 and that alone does not justify the introduction of device specific images imho. Greetings, First of all, I am sorry for the problems caused by the commit I made back then. Unfortunately, there are three more problems: First, the kmod-leds-mlxcpld module cannot be probed during boot on other x86 devices, resulting in the following error message: [ 8.531720] kmodloader: 1 module could not be probed [ 8.532613] kmodloader: - leds-mlxcpld - 0 Second, only the firmware files for the Spectrum-1 Series (SN2XXX) have been added so far. Originally, we had plans to add the firmware files for the Spectrum-2, -3, and -4 Series as well. The current Spectrum-4 Series firmware files are even 8MB big (although it seems they are only supported from Kernel version 6.2 onward). And last, Mellanox doesn't even recommend the firmware file flashed by the driver: https://github.com/Mellanox/mlxsw/wiki/5.15-Release-notes#supported-firmware. So you should actually flash another one, which means we would theoretically need two firmware files for each Spectrum Series. But I haven't run into problems yet with the one the driver flashed. I think removing the packages from the default x86 is the best solution for now, so they must be manually added while configuring the image. Later, they could be still added back to the appropriate target, if there might be a better solution. I also just opened a pull request (#13981) regarding that. Kind regards Til ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
David Bauer [2023-11-14 10:02:36]: Hi, > Is there already a patch series / PR in the works? AFAIK there is just PR #13924 attempting to workaround #13886 > Otherwise, I'd look into that. Great, thanks! Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Hi Daniel, Hi Petr, On 11/13/23 21:49, Daniel Golle wrote: On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote: Paul Spooren [2023-11-13 13:30:10]: Hi, 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? FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead recommend to fix that mlx firmware package and call it a day? Thanks for pointing this out, increasing the default image by 1.6MiB is bearable on x86 and that alone does not justify the introduction of device specific images imho. Sounds reasonable to me, regardless of how we want to proceed with the x64 target in general. Is there already a patch series / PR in the works? Otherwise, I'd look into that. Best David ___ 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
Re: Adding a new x86 image or related packages to the default x86 image
> On Nov 13, 2023, at 10:44 PM, Elliott Mitchell wrote: > > On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote: >> On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: >>> On Mon, Nov 13, 2023 at 12:48:14PM +, 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. >> >> Using squashfs (which is what we are doing) has actually quite >> a similar effect than using initramfs. Filesystem cache of files which >> aren't accessed gets freed. >> >> What is missing is hotplug-based loading of kmods based on present >> devices -- right now every module present gets loaded and remains >> loaded indefinitely even if the hardware isn't present. > > First, an initial ramdisk allows the kernel to not include any block > drivers, but instead load them during boot. ie a VM build could include > drivers for interacting with every hypervisor, but only load the ones > for the hypervisor in use. > > Second, while suboptimal having those drivers as modules allows them to > be unloaded. If the drivers for every hypervisor were unconditionally > loaded, the inappropriate ones might be unloaded by /etc/rc.local. > > >>> Each hypervisor will have a small set of drivers guaranteed to be >>> present. These though will be completely different between hypervisors. >> >> Do you really think having just the (partially shared) drivers for 3 >> hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too >> much? Those drivers are very tiny... > > Permanently built into the kernel? Not acceptable. Every once-in-a-while a vulnerable driver is discovered that is a CVE even when it's not active. Having the modules linked in makes it harder to blacklist their initialization. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Tue, Nov 14, 2023 at 03:44:57AM +, Daniel Golle wrote: > On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > > On Mon, Nov 13, 2023 at 12:48:14PM +, 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. > > Using squashfs (which is what we are doing) has actually quite > a similar effect than using initramfs. Filesystem cache of files which > aren't accessed gets freed. > > What is missing is hotplug-based loading of kmods based on present > devices -- right now every module present gets loaded and remains > loaded indefinitely even if the hardware isn't present. First, an initial ramdisk allows the kernel to not include any block drivers, but instead load them during boot. ie a VM build could include drivers for interacting with every hypervisor, but only load the ones for the hypervisor in use. Second, while suboptimal having those drivers as modules allows them to be unloaded. If the drivers for every hypervisor were unconditionally loaded, the inappropriate ones might be unloaded by /etc/rc.local. > > Each hypervisor will have a small set of drivers guaranteed to be > > present. These though will be completely different between hypervisors. > > Do you really think having just the (partially shared) drivers for 3 > hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too > much? Those drivers are very tiny... Permanently built into the kernel? Not acceptable. Having a single shared initial ramdisk which always loads all modules for every hypervisor? Acceptable. Tiny is relative. For a bare-metal computer with 128GB of memory, 10MB isn't going to make too much difference. For a 128MB VM, 10MB does make a significant difference. > > 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. > However, OpenWrt (the distribution) supports thousands of different > devices, and that becomes possible only because all devices within a > subtarget share use the exact same kernel build. Not just because of > build resources, but also because almost all testing and debugging is > covered in the subtarget level and hence we are talking about a > somehow manageable workload -- one can nearly reproduce and debug > most issues on any of the devices (can be hundreds) on a subtarget > using a single or at most 4 different reference devices. Hmm. As stated above, having everything as a module is acceptable to me. The issue here is there isn't much use of modules in OpenWRT. On Mon, Nov 13, 2023 at 09:33:38PM -0700, Philip Prindeville wrote: > > > On Nov 13, 2023, at 7:26 PM, Elliott Mitchell wrote: > > > > Each hypervisor will have a small set of drivers guaranteed to be > > present. These though will be completely different between hypervisors. > > With KVM and kmod-vfio-pci you can do reverse-pass thru where the host isn't > controlling the hardware but the guest is. I know some people who do this to > test WiFi drivers from KVM guests. > I haven't tested this with every hypervisor, but I'm pretty sure every hypervisor of note can do this. The configuration steps are different, but the result is exactly the same. You're thinking too small. This can be used for testing, but this is also entirely feasible for a serious use AP in a VM. As stated previously, the makers of embedded acces points have been suggesting pushing server tasks onto your AP. Yet the opposite is possible, a server can have all the hardware for a full AP. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \BS (| ehem+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include 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/l
Re: Adding a new x86 image or related packages to the default x86 image
> On Nov 13, 2023, at 7:26 PM, Elliott Mitchell wrote: > > On Mon, Nov 13, 2023 at 12:48:14PM +, 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). > > [...] > > 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. With KVM and kmod-vfio-pci you can do reverse-pass thru where the host isn't controlling the hardware but the guest is. I know some people who do this to test WiFi drivers from KVM guests. -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 06:26:04PM -0800, Elliott Mitchell wrote: > On Mon, Nov 13, 2023 at 12:48:14PM +, 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. Using squashfs (which is what we are doing) has actually quite a similar effect than using initramfs. Filesystem cache of files which aren't accessed gets freed. What is missing is hotplug-based loading of kmods based on present devices -- right now every module present gets loaded and remains loaded indefinitely even if the hardware isn't present. > > 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. You can already do that and the effect on memory consumption is the same as an initrd (which is literally just uncommitted filesystem cache). The only difference is that the initramfs needs to be decompressed in one piece which takes a lot of time while squashfs can be read and decompressed on-the-fly obviously. And initramfs needs to be explicitely freed (using pivot_root) while in case of squashfs files can always be loaded from flash and stay in the filesystem cache in RAM as long as they are being used and the space isn't needed for anything else. > > > 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. Here I agree. We should have a 'slim/vm' image without any 'real' hardware drivers. > > Each hypervisor will have a small set of drivers guaranteed to be > present. These though will be completely different between hypervisors. Do you really think having just the (partially shared) drivers for 3 hypervisors (KVM/virtio, Hyper-V, VMWare) present in one image is too much? Those drivers are very tiny... > > 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. Framebuffer support can entirely be built as modules and we can do that instead of having it built-in on x86. Feel free to suggest patches. > > 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. Ok, that would really require different kernel builds (as in: subtargets) and not just different images. One for booting from all kinds of physical storage and one for booting from virtualized virtio block or NVMe via IOMMU. > > 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. I understand the additional build resources, maintainance and debugging efforts can be justified when having a very high number of identical devices, as it is typically the case only in very large deployments (think: major ISPs and hotspot providers having in-house R&D). However, OpenWrt (the distribution) supports thousands of different devices, and that becomes possible only because all devices within a subtarget share use the exact same kernel build. Not just because of build resources, but also because almost all testing and debugging is covered in the subtarget level and hence we are talking about a somehow manageable workload -- one can nearly reproduce and debug most issues on any of the devices (can be hundreds) on a subtarget using a single or at most 4 different reference devices. OpenWrt (the build-system) could offer such a feature for people wanting to create super-optimizied builds themselves. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 12:48:14PM +, 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+sig...@m5p.com PGP 87145445 |) / \_CS\ | _ -O #include 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
Re: Adding a new x86 image or related packages to the default x86 image
On Mon, Nov 13, 2023 at 07:54:34PM +, Petr Štetiar wrote: > Paul Spooren [2023-11-13 13:30:10]: > > Hi, > > > 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? > > FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 > image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob > mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead > recommend to > fix that mlx firmware package and call it a day? Thanks for pointing this out, increasing the default image by 1.6MiB is bearable on x86 and that alone does not justify the introduction of device specific images imho. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Paul Spooren [2023-11-13 13:30:10]: Hi, > 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? FYI that pull request added 27 firmware ASIC blobs, thus increased x86/64 image from 10 MiB to 41 MiB, but actually just 1 firmware ASIC blob mlxsw_spectrum-13.2010.1006.mfa2 (1.6MiB) is needed, so I would instead recommend to fix that mlx firmware package and call it a day? Cheers, Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
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 wrote:
> >
> >> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann 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 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
Re: Adding a new x86 image or related packages to the default x86 image
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 wrote:
>
>> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann 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 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
Re: Adding a new x86 image or related packages to the default x86 image
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann 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 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
Re: Adding a new x86 image or related packages to the default x86 image
> On Sep 14, 2023, at 5:19 PM, Stefan Lippers-Hollmann wrote:
>
> Hi
>
> On 2023-09-14, Paul Spooren wrote:
>> Hi,
>>
>> 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.
>
> Regards
> Stefan Lippers-Hollmann
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.
-Philip
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Hi, > I'd suggest to stick to a single x86_64 image for maintenance and testing > reasons alone I agree. Furthermore, x86 devices have often no device identity like other devices using device tree do. With the current implementation, the attended sysupgrade service would be broken since on x86 always use the “generic” image. @David since you pulled the PR[1] to your staging tree[2], do you mind modifying the commits (for now) that the new packages are added to the default image? Best, Paul [1]: https://github.com/openwrt/openwrt/pull/13418 [2]: https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=summary ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Adding a new x86 image or related packages to the default x86 image
Hi
On 2023-09-14, Paul Spooren wrote:
> Hi,
>
> 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.
Regards
Stefan Lippers-Hollmann
pgpbyqv1ZCjkx.pgp
Description: Digitale Signatur von OpenPGP
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Adding a new x86 image or related packages to the default x86 image
Hi, 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? Just defining the packages without adding a pre-selection of them to work on the Mellanox doesn’t strike me as a nice solution since it wouldn’t create a “out of the box” installable image. Thanks for comments, Paul [1]: https://github.com/openwrt/openwrt/pull/13418 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
