Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On 29.04.23 02:50, Elliott Mitchell wrote: On Thu, Apr 27, 2023 at 05:38:18AM +0200, Stefan Lippers-Hollmann wrote: On 2023-04-26, Elliott Mitchell wrote: > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > On 2023-04-26, Elliott Mitchell wrote: > > [...] > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > from the top-level configuration. Geode and Legacy though almost > > > certainly still need ISA support. > > > > You might find that while ISA went away as an addon slot quite quickly, > > it still survived rather long for low performance onboard devices (e.g. > > sensors). > > I know, I was unsure of when it 100% disappeared. Do you expect anything > besides "legacy" to be used for this type of system though? [...] Ignoring industrial PCs (where you may still encounter ISA today), you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia might have gone with ISA beyond that) - which might get you into the 2005-2009 time frame (anything with an onboard floppy controller might be worth looking at - and those were still around into the LGA755/ core2 (x86_64) days - in that particular case probably LPC based though). Perhaps have "64" and "old64" (or "early64") then? Seems rather a lot of legacy disappeared between 2005 and 2010. FDC, ISA, PATA and AGP were all common in 2005, yet by 2010 they were non-existant. If you need a build for yourself with a specialized stripped down kernel config, there is an easy (and reasonably maintainable) approach to doing so. First you need to use this: https://openwrt.org/docs/guide-developer/toolchain/env Create an env for your main config. Afterwards, you can run: make kernel_menuconfig CONFIG_TARGET=env Any change you make there will be stored in env/kernel-config, which is an overlay that is applied on top of the target config. You can use it to disable any features you like without having to modify any files in the OpenWrt source directory, and it should continue to work with pretty much any source tree updates. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On Thu, Apr 27, 2023 at 05:38:18AM +0200, Stefan Lippers-Hollmann wrote: > On 2023-04-26, Elliott Mitchell wrote: > > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > > On 2023-04-26, Elliott Mitchell wrote: > > > [...] > > > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > > from the top-level configuration. Geode and Legacy though almost > > > > certainly still need ISA support. > > > > > > You might find that while ISA went away as an addon slot quite quickly, > > > it still survived rather long for low performance onboard devices (e.g. > > > sensors). > > > > I know, I was unsure of when it 100% disappeared. Do you expect anything > > besides "legacy" to be used for this type of system though? > [...] > > Ignoring industrial PCs (where you may still encounter ISA today), > you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia > might have gone with ISA beyond that) - which might get you into > the 2005-2009 time frame (anything with an onboard floppy controller > might be worth looking at - and those were still around into the > LGA755/ core2 (x86_64) days - in that particular case probably LPC > based though). Perhaps have "64" and "old64" (or "early64") then? Seems rather a lot of legacy disappeared between 2005 and 2010. FDC, ISA, PATA and AGP were all common in 2005, yet by 2010 they were non-existant. -- (\___(\___(\__ --=> 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: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
> On Apr 26, 2023, at 2:11 PM, Elliott Mitchell wrote: > > Now we come to the item I've mentioned. The X32 ABI. This is running an > amd64 processor in amd64 mode, but truncating all pointers to 32 bits > (ILP32 mode). This shrinks the runtime size of programs in exchange for > limiting them to a maximum of 4GB of memory. The result is often a > significant speed increase over both i386 and amd64 modes, largely due to > reducing memory use. > > For rather a lot of programs, 4GB of memory is plenty. Have you ever > observed `ls` or a shell use anywhere near that much? The fact most > devices running OpenWRT don't have that much *total* memory says the > limitation is worthwhile. Personally I don't want to relive thunking hell. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
Hi On 2023-04-26, Elliott Mitchell wrote: > On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > > On 2023-04-26, Elliott Mitchell wrote: > > [...] > > > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > > due to the generic configuration. Remove the ISA and ISA DMA support > > > from the top-level configuration. Geode and Legacy though almost > > > certainly still need ISA support. > > > > You might find that while ISA went away as an addon slot quite quickly, > > it still survived rather long for low performance onboard devices (e.g. > > sensors). > > I know, I was unsure of when it 100% disappeared. Do you expect anything > besides "legacy" to be used for this type of system though? [...] Ignoring industrial PCs (where you may still encounter ISA today), you'd have to venture into the pre-LPC days (and AMD, VIA, nVidia might have gone with ISA beyond that) - which might get you into the 2005-2009 time frame (anything with an onboard floppy controller might be worth looking at - and those were still around into the LGA755/ core2 (x86_64) days - in that particular case probably LPC based though). Regards Stefan Lippers-Hollmann pgptGI7NfSgkh.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On Thu, Apr 27, 2023 at 01:11:13AM +0200, Stefan Lippers-Hollmann wrote: > On 2023-04-26, Elliott Mitchell wrote: > [...] > > > > Looks like little of ISA remained on "64", yet some DMA support remained > > due to the generic configuration. Remove the ISA and ISA DMA support > > from the top-level configuration. Geode and Legacy though almost > > certainly still need ISA support. > > You might find that while ISA went away as an addon slot quite quickly, > it still survived rather long for low performance onboard devices (e.g. > sensors). I know, I was unsure of when it 100% disappeared. Do you expect anything besides "legacy" to be used for this type of system though? My larger concern is the x86 default should be "no" since this is less than 50% of cases. As such target/linux/x86/config-* should have CONFIG_ISA=n and only the special builds which need it should enable it. > > In case someone doesn't know, "AGP" is short for "Accelerated Graphics > > Port". This was an interim standard when graphics cards in the late > > 1990s were overwhelming PCI, but PCI-Express wasn't yet available. Since > > OpenWRT is a router distribution, this doesn't seem like a good fit. If > > you've got such an Intel board, this will reduce graphics performance, > > but will release ~.5MB extra memory for better uses. > > While *I personally* wouldn't consider systems of this vintage for 24/7 > operations (power consumption alone), AGP has been in use for quite a > while longer than that (mid 2000s). I do still have (fully functional) > Pentium 4 and AMD64 systems with AGP graphics. Mine are long gone. I believe AGP though is a PCI superset. Disabling AGP support is supposed to reduce performance, but keep the bus functional. Mainly it merely behaves as a very fast PCI bus instead of having extra features. There has been discussion of removing AGP support from the Linux kernel. > I have responded to DRM and x86_x32 individually, but while I understand > these proposals from a virtualization-only point of view, they are not > very useful on real x86/ x86_64 hardware - up to the point of being > actively harmful in breaking support for existing hardware. Please point to a patch and cite an example of existing hardware it breaks*. * reduced performance is not breaking support, pushing hardware onto legacy isn't breaking support either > (It's pointless to enable x32, unless you can demonstrate that OpenWrt's > buildsystem can successfully build for it, with a 32 bit userland and > 64 bit kernels). Enabling the kernel support is the first step in the process of getting x32 operational. -- (\___(\___(\__ --=> 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: [PATCH 0/9] (mostly) x86 kernel configuration adjustments
On 2023-04-26, Elliott Mitchell wrote: [...] > > Looks like little of ISA remained on "64", yet some DMA support remained > due to the generic configuration. Remove the ISA and ISA DMA support > from the top-level configuration. Geode and Legacy though almost > certainly still need ISA support. You might find that while ISA went away as an addon slot quite quickly, it still survived rather long for low performance onboard devices (e.g. sensors). > In case someone doesn't know, "AGP" is short for "Accelerated Graphics > Port". This was an interim standard when graphics cards in the late > 1990s were overwhelming PCI, but PCI-Express wasn't yet available. Since > OpenWRT is a router distribution, this doesn't seem like a good fit. If > you've got such an Intel board, this will reduce graphics performance, > but will release ~.5MB extra memory for better uses. While *I personally* wouldn't consider systems of this vintage for 24/7 operations (power consumption alone), AGP has been in use for quite a while longer than that (mid 2000s). I do still have (fully functional) Pentium 4 and AMD64 systems with AGP graphics. I have responded to DRM and x86_x32 individually, but while I understand these proposals from a virtualization-only point of view, they are not very useful on real x86/ x86_64 hardware - up to the point of being actively harmful in breaking support for existing hardware. (It's pointless to enable x32, unless you can demonstrate that OpenWrt's buildsystem can successfully build for it, with a 32 bit userland and 64 bit kernels). Regards Stefan Lippers-Hollmann pgpI7VuI7p1FI.pgp Description: Digitale Signatur von OpenPGP ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/9] (mostly) x86 kernel configuration adjustments
I've been mentioning the issue several times, but the OpenWRT x86 builds really don't seem to fit well. As such several x86 kernel configuration adjustments I think are appropriate. First, a side issue. The "# CONFIG_ is not set" was meant for use by tools. Theory being almost all options would default to "no" therefore this implied the person doing configuration had left them alone. Setting an option to "n" is more common when configurations are handled manually. Most tools work perfectly with this and I suggest this should be preferred, when appropriate, going forward. First up is the simple observation CONFIG_FB_NOTIFY disappeared at some point. Since it no longer does anything, the setting should be purged. Next up is some bits related to hardware random-number generators. I notice rather more kernel configuration files set CONFIG_HW_RANDOM to yes than set it to no. As such having the default be yes is a win. Right now this is a mild improvement, but HW RNGs are becoming more common so this should improve over time. I also found support for the Geode HW random number generator had gotten into the common x86 configuration. I imagine having the support is advantageous to Geode devices. Anything else it is disadvantageous. What originally brought the Geode HW RNG situation to my attention was noticing CONFIG_SCx200. Appears CONFIG_SCx200 is part of the Geode platform. Similar to the previous I don't doubt Geode systems need the driver. Non-Geode x86 though simply don't. Appears the architecture type CONFIG_M values need to be set to something. They should all be unset in the common file though. All of the subtargets explicitly specify some processor. Now we come to the item I've mentioned. The X32 ABI. This is running an amd64 processor in amd64 mode, but truncating all pointers to 32 bits (ILP32 mode). This shrinks the runtime size of programs in exchange for limiting them to a maximum of 4GB of memory. The result is often a significant speed increase over both i386 and amd64 modes, largely due to reducing memory use. For rather a lot of programs, 4GB of memory is plenty. Have you ever observed `ls` or a shell use anywhere near that much? The fact most devices running OpenWRT don't have that much *total* memory says the limitation is worthwhile. The difficulty is this means bringing up a new toolchain. While the deltas are small, compilers, linkers and libc all need minor adjustments. The other question is whether to have separate amd64 (or "64") and x32 builds, versus a single combined one. Looks like little of ISA remained on "64", yet some DMA support remained due to the generic configuration. Remove the ISA and ISA DMA support from the top-level configuration. Geode and Legacy though almost certainly still need ISA support. In case someone doesn't know, "AGP" is short for "Accelerated Graphics Port". This was an interim standard when graphics cards in the late 1990s were overwhelming PCI, but PCI-Express wasn't yet available. Since OpenWRT is a router distribution, this doesn't seem like a good fit. If you've got such an Intel board, this will reduce graphics performance, but will release ~.5MB extra memory for better uses. The Direct Rendering Manager was created in association with XFree86. The goal was making graphics faster and moving some things which had been implemented in XFree86, but really needed to be in the kernel into the kernel. I suspect Wayland may well depend on some or all of this. Yet isn't OpenWRT's target embedded network devices? This is something needed for a graphics desktop, not an embedded networking devices (unless you're trying to create X-terminals). As such this also seems like a misfit for OpenWRT/x86. Elliott Mitchell (9): kernel/generic: remove CONFIG_FB_NOTIFY kernel: change CONFIG_HW_RANDOM default to y kernel/x86: move Geode HW random from generic to geode kernel/x86: move SCx200 support from generic to geode kernel/x86: remove CONFIG_M686 from common configuration kernel/x86: enable x32 support for amd64 kernel/x86: remove all ISA support from non-legacy kernel/x86: remove support for AGP kernel/x86: remove DRM support target/linux/airoha/config-5.15 | 1 - target/linux/apm821xx/config-5.10 | 1 - target/linux/apm821xx/config-5.15 | 1 - target/linux/archs38/config-5.10| 1 + target/linux/archs38/config-5.15| 1 + target/linux/armvirt/32/config-5.10 | 1 + target/linux/armvirt/32/config-5.15 | 1 + target/linux/armvirt/64/config-5.10 | 1 - target/linux/armvirt/64/config-5.15 | 1 - target/linux/ath25/config-5.10 | 1 - target/linux/ath79/config-5.10 | 1 + target/linux/ath79/config-5.15 | 1 + target/linux/bcm47xx/config-5.10| 1 - target/linux/bcm47xx/config-5.15| 1 - target/linux/bcm4908/config-5.10| 1 + target/linu