[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_<name> 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<proc> 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/linux/bcm4908/config-5.15            |  1 +
 target/linux/bcm53xx/config-5.10            |  1 -
 target/linux/bcm53xx/config-5.15            |  1 -
 target/linux/bcm63xx/config-5.15            |  1 -
 target/linux/gemini/config-5.10             |  1 +
 target/linux/gemini/config-5.15             |  1 -
 target/linux/generic/config-5.10            |  3 +-
 target/linux/generic/config-5.15            |  3 +-
 target/linux/imx/config-5.15                |  1 -
 target/linux/ipq40xx/config-5.15            |  1 -
 target/linux/ipq806x/config-5.10            |  1 -
 target/linux/ipq806x/config-5.15            |  1 -
 target/linux/ipq807x/config-5.15            |  1 +
 target/linux/kirkwood/config-5.10           |  1 -
 target/linux/kirkwood/config-5.15           |  1 -
 target/linux/lantiq/ase/config-5.10         |  1 -
 target/linux/lantiq/ase/config-5.15         |  1 -
 target/linux/lantiq/falcon/config-5.10      |  1 +
 target/linux/lantiq/falcon/config-5.15      |  1 +
 target/linux/lantiq/xrx200/config-5.10      |  1 -
 target/linux/lantiq/xrx200/config-5.15      |  1 -
 target/linux/lantiq/xway/config-5.10        |  1 -
 target/linux/lantiq/xway/config-5.15        |  1 -
 target/linux/lantiq/xway_legacy/config-5.10 |  1 +
 target/linux/lantiq/xway_legacy/config-5.15 |  1 +
 target/linux/malta/config-5.10              |  1 +
 target/linux/malta/config-5.15              |  1 +
 target/linux/mpc85xx/config-5.10            |  1 -
 target/linux/mpc85xx/config-5.15            |  1 -
 target/linux/mvebu/config-5.10              |  1 -
 target/linux/mvebu/config-5.15              |  1 -
 target/linux/mxs/config-5.15                |  1 +
 target/linux/octeon/config-5.10             |  1 -
 target/linux/octeon/config-5.15             |  1 -
 target/linux/octeontx/config-5.15           |  1 -
 target/linux/omap/config-5.10               |  1 -
 target/linux/omap/config-5.15               |  1 -
 target/linux/oxnas/config-5.15              |  1 +
 target/linux/pistachio/config-5.10          |  1 +
 target/linux/pistachio/config-5.15          |  1 +
 target/linux/qoriq/config-5.15              |  1 -
 target/linux/sunxi/config-5.15              |  1 -
 target/linux/tegra/config-5.10              |  1 +
 target/linux/tegra/config-5.15              |  1 +
 target/linux/uml/config-5.10                |  1 -
 target/linux/uml/config-5.15                |  1 -
 target/linux/x86/64/config-5.10             | 46 ------------------
 target/linux/x86/64/config-5.15             | 46 ------------------
 target/linux/x86/config-5.10                | 16 +++---
 target/linux/x86/config-5.15                | 16 +++---
 target/linux/x86/generic/config-5.10        | 51 -------------------
 target/linux/x86/generic/config-5.15        | 51 -------------------
 target/linux/x86/geode/config-5.10          |  8 ++-
 target/linux/x86/geode/config-5.15          |  8 ++-
 target/linux/x86/legacy/config-5.10         | 54 +--------------------
 target/linux/x86/legacy/config-5.15         | 54 +--------------------
 target/linux/zynq/config-5.15               |  1 +
 72 files changed, 55 insertions(+), 361 deletions(-)

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

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.

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

> On Apr 26, 2023, at 2:11 PM, Elliott Mitchell <ehem+openwrt@m5p.com> 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.

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.

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