[PATCH 1/1] kernel/x86: merge "generic" into "legacy"

Elliott Mitchell ehem+openwrt at m5p.com
Wed Jan 3 20:31:25 PST 2024


On Tue, Jan 02, 2024 at 04:44:04PM -0800, Elliott Mitchell wrote:
> There is a desire to reduce the time spent on x86 OpenWRT platforms.
> "generic" is most suitable for removal.  The few systems which could
> use "generic" must now opt for "legacy" (or for a lucky few "64").

In case it wasn't obvious, I simply grabbed everything in "generic"'s
config-6.1 file and merged it into the "legacy" version.  I did a little
bit of filtering, alas I definitely missed some crucial bits.  OTOH some
of the things which had gotten into the "generic" config-6.1 file seem
revealing...


> diff --git a/target/linux/x86/legacy/config-6.1 b/target/linux/x86/legacy/config-6.1
> index d4b05e4642..325909c409 100644
> --- a/target/linux/x86/legacy/config-6.1
> +++ b/target/linux/x86/legacy/config-6.1

> @@ -92,35 +113,91 @@ CONFIG_DRM_RADEON=y
>  CONFIG_DRM_SCHED=y
>  CONFIG_DRM_TTM=y
>  CONFIG_DRM_TTM_HELPER=y
> +CONFIG_DRM_VIRTIO_GPU=y
>  CONFIG_DRM_VRAM_HELPER=y
> +CONFIG_EFI=y
> +CONFIG_EFIVAR_FS=m

I'm unsure about this.  I don't know whether any P4s actually had EFI
firmware.  According to the handy resource, initial versions of EFI were
out by 2004 so some P4s might have had EFI.  I never touched them due to
their terrible characteristics so I don't actually know.

> +CONFIG_HIGHMEM64G=y
> +CONFIG_HOTPLUG_CPU=y
> +CONFIG_HOTPLUG_PCI=y
> +CONFIG_HOTPLUG_PCI_ACPI=y
> +# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
> +# CONFIG_HOTPLUG_PCI_COMPAQ is not set
> +# CONFIG_HOTPLUG_PCI_CPCI is not set
> +# CONFIG_HOTPLUG_PCI_IBM is not set
> +CONFIG_HOTPLUG_PCI_PCIE=y
> +# CONFIG_HOTPLUG_PCI_SHPC is not set
> +CONFIG_HOTPLUG_SMT=y

Some of Intel's Xeons might have allowed for 64GB.  More than 4GB were
quite few and far between.  Other than USB actual hot-plug hardware was
rather sparse, yet "generic" did have these.

> @@ -154,15 +237,38 @@ CONFIG_ISA_BUS_API=y
>  CONFIG_ISO9660_FS=y
>  # CONFIG_JOLIET is not set
>  CONFIG_KCMP=y
> +CONFIG_KVM=y
> +CONFIG_KVM_AMD=y
> +CONFIG_KVM_ASYNC_PF=y
> +CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
> +CONFIG_KVM_GUEST=y
> +CONFIG_KVM_INTEL=y
> +CONFIG_KVM_MMIO=y
> +CONFIG_KVM_VFIO=y
> +# CONFIG_KVM_XEN is not set
> +CONFIG_KVM_XFER_TO_GUEST_WORK=y

Apparently it is genuinely possible to use KVM on some non-amd64 x86
processors.

> @@ -178,13 +284,35 @@ CONFIG_MOUSE_PS2_SYNAPTICS=y
>  CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
>  # CONFIG_MOUSE_PS2_TOUCHKIT is not set
>  CONFIG_MOUSE_PS2_TRACKPOINT=y
> +# CONFIG_MOUSE_PS2_VMMOUSE is not set
>  # CONFIG_MOUSE_SERIAL is not set
>  # CONFIG_MOUSE_VSXXXAA is not set
> +CONFIG_MPENTIUM4=y

Oops.  Goof with the very limited filtering I did.  This one needs to be
pulled.

> +CONFIG_NR_CPUS=4
> +CONFIG_NR_CPUS_DEFAULT=8
> +CONFIG_NR_CPUS_RANGE_BEGIN=2
> +CONFIG_NR_CPUS_RANGE_END=8

4 processors is very high-end for this type of machine, but they did
exist.

> @@ -202,24 +331,77 @@ CONFIG_PCIEASPM_DEFAULT=y
>  # CONFIG_PCIEASPM_POWERSAVE is not set
>  # CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
>  CONFIG_PCIEPORTBUS=y
> +CONFIG_PCIE_PME=y
>  CONFIG_PCI_MMCONFIG=y
> +CONFIG_PCI_XEN=y
>  # CONFIG_PCWATCHDOG is not set
>  # CONFIG_PEAQ_WMI is not set
> +CONFIG_PGTABLE_LEVELS=3
> +CONFIG_PHYS_ADDR_T_64BIT=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_ALDERLAKE=y
> +CONFIG_PINCTRL_BAYTRAIL=y
> +CONFIG_PINCTRL_BROXTON=y
> +CONFIG_PINCTRL_CANNONLAKE=y
> +CONFIG_PINCTRL_CHERRYVIEW=y
> +CONFIG_PINCTRL_DENVERTON=y
> +CONFIG_PINCTRL_ELKHARTLAKE=y
> +CONFIG_PINCTRL_EMMITSBURG=y
> +CONFIG_PINCTRL_GEMINILAKE=y
> +CONFIG_PINCTRL_INTEL=y
> +CONFIG_PINCTRL_JASPERLAKE=y
> +CONFIG_PINCTRL_LAKEFIELD=y
> +CONFIG_PINCTRL_LEWISBURG=y
> +CONFIG_PINCTRL_LYNXPOINT=y
> +CONFIG_PINCTRL_METEORLAKE=y
> +CONFIG_PINCTRL_SUNRISEPOINT=y
> +CONFIG_PINCTRL_TIGERLAKE=y

Yes, CONFIG_X86_INTEL_LPSS=y made its way into "generic" and thus it got
here.  I'm unaware of any of these ever being paired with a non-amd64
processor.  This seems wrong, but that is what was in "generic".

> +CONFIG_SENSORS_CORETEMP=y
> +CONFIG_SENSORS_FAM15H_POWER=y
> +CONFIG_SENSORS_I5500=y
> +CONFIG_SENSORS_K10TEMP=y
> +CONFIG_SENSORS_K8TEMP=y
> +CONFIG_SENSORS_VIA_CPUTEMP=y

I might complain about all the silly Intel-specific choices, but these
AMD-specific ones are equally ridiculous.  These couldn't be paired with
anything you would use with "generic" or "legacy".  Yet this *is* what
was there!

> +CONFIG_SMP=y

Much less common with "legacy" and "generic" hardware, but there were
plenty of these machines around.  This should already have been in
"legacy".

> @@ -228,34 +410,101 @@ CONFIG_SERIAL_8250_PNP=y

> +CONFIG_VIRTIO=y
> +CONFIG_VIRTIO_BALLOON=y
> +CONFIG_VIRTIO_BLK=y
> +CONFIG_VIRTIO_CONSOLE=y
> +CONFIG_VIRTIO_DMA_SHARED_BUFFER=y
> +CONFIG_VIRTIO_INPUT=y
> +CONFIG_VIRTIO_MMIO=y
> +CONFIG_VIRTIO_NET=y
> +CONFIG_VIRTIO_PCI=y
> +CONFIG_VIRTIO_PCI_LEGACY=y
> +CONFIG_VIRTIO_PCI_LIB=y
> +# CONFIG_VIRTIO_PMEM is not set
> +CONFIG_VIRTUALIZATION=y

Rather less commonly used for "legacy"-class machines, but it was
genuinely available.

> +CONFIG_XEN=y
> +CONFIG_XENFS=y
> +CONFIG_XEN_ACPI=y
> +CONFIG_XEN_AUTO_XLATE=y
> +# CONFIG_XEN_BACKEND is not set
> +CONFIG_XEN_BALLOON=y
> +CONFIG_XEN_BLKDEV_FRONTEND=y
> +CONFIG_XEN_COMPAT_XENFS=y
> +CONFIG_XEN_DEBUG_FS=y
> +CONFIG_XEN_DEV_EVTCHN=y
> +CONFIG_XEN_FBDEV_FRONTEND=y
> +CONFIG_XEN_GNTDEV=y
> +CONFIG_XEN_GRANT_DEV_ALLOC=y
> +CONFIG_XEN_NETDEV_FRONTEND=y
> +CONFIG_XEN_PRIVCMD=y
> +CONFIG_XEN_PVH=y
> +CONFIG_XEN_PVHVM=y
> +CONFIG_XEN_PVHVM_GUEST=y
> +CONFIG_XEN_PVHVM_SMP=y
> +CONFIG_XEN_SAVE_RESTORE=y
> +CONFIG_XEN_SCSI_FRONTEND=y
> +CONFIG_XEN_SYS_HYPERVISOR=y
> +CONFIG_XEN_VIRTIO=y
> +# CONFIG_XEN_VIRTIO_FORCE_GRANT is not set
> +CONFIG_XEN_WDT=y
> +CONFIG_XEN_XENBUS_FRONTEND=y

Xen got started on this class of machine.  At the time 4GB of memory
would have been a $20K+ computer, but these did exist.  Anything "legacy"
*can* use Xen, though I'm doubtful very many people will continue to use
it on this type of hardware.


Anyway, a number of people have expressed a desire to reduce the count of
x86 targets by at least one.  Is anyone going to turn expression into
action?


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg at m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445





More information about the openwrt-devel mailing list