openwrt icon indicating copy to clipboard operation
openwrt copied to clipboard

kernel/x86: merge "generic" into "legacy"

Open ehem opened this issue 11 months ago • 4 comments

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").

Closes: #14231

ehem avatar Mar 20 '24 21:03 ehem

Also please prepare patches for kernel 6.6 so that the PR is ready for commit https://github.com/openwrt/openwrt/pull/14868

namiltd avatar Mar 20 '24 22:03 namiltd

There wouldn't be much difference. Simply duplicates everything for 6.6. If this got approved quickly it might go in before #14868.

ehem avatar Mar 20 '24 23:03 ehem

The order of approval is still a mystery to me ;)

namiltd avatar Mar 20 '24 23:03 namiltd

Just as long as the order of operations isn't. What is really needed is opinions on which options should really be copied from generic. Rather a lot of those don't really fit even for late model i386-class machines (EFI is quite rare, the few machines with it could almost certainly support traditional x86 BIOS boot too).

ehem avatar Mar 21 '24 00:03 ehem

I guess we could almost simply dump generic. The extra settings in generic are likely rarely used on non-amd64, whereas the late-model P4s should be on 64.

Any comments on whether any of these should be dumped instead of propagated to legacy?

ehem avatar Apr 02 '24 03:04 ehem

Hmm, unsure why I deleted the branch. Perhaps didn't want markers hanging around in git, and goofed on which one #14944 was tied to. Automatically closing pull requests isn't helpful.

ehem avatar May 08 '24 03:05 ehem

The more I look at this, the more I'm favoring simply deleting "generic" instead of merging it into "legacy". The reason being "generic" has too many settings appropriate for a mid-end machine. Merging it into "legacy" may well bloat "legacy" enough that it no longer runs on most legacy-class systems. Whereas most systems which want those settings can instead run "64".

About the only thing possibly appropriate to merge into "legacy" is the Xen support. Xen could be used on genuine legacy-class hardware.

ehem avatar May 08 '24 04:05 ehem

The build of the legacy target fails like this:

====== Make errors from logs/target/linux/compile.txt ======
  MTRR cleanup support (MTRR_SANITIZER) [N/y/?] n
  x86 PAT support (X86_PAT) [Y/n/?] y
User Mode Instruction Prevention (X86_UMIP) [Y/n/?] y
TSX enable mode
> 1. off (X86_INTEL_TSX_MODE_OFF)
  2. on (X86_INTEL_TSX_MODE_ON)
  3. auto (X86_INTEL_TSX_MODE_AUTO)
choice[1-3?]: 1
EFI runtime service support (EFI) [Y/n/?] y
  EFI stub support (EFI_STUB) [Y/n/?] y
    EFI handover protocol (DEPRECATED) (EFI_HANDOVER_PROTOCOL) [Y/n/?] (NEW) make[7]: *** [scripts/kconfig/Makefile:77: syncconfig] Error 1
make[6]: *** [Makefile:697: syncconfig] Error 2
make[5]: *** [/__w/openwrt/openwrt/openwrt/build_dir/target-i486-openwrt-linux-musl_musl/linux-x86_legacy/linux-6.6.30/Makefile:798: include/config/auto.conf.cmd] Error 2
make[4]: *** [Makefile:234: __sub-make] Error 2
make[3]: *** [Makefile:26: /__w/openwrt/openwrt/openwrt/build_dir/target-i486-openwrt-linux-musl_musl/linux-x86_legacy/linux-6.6.30/.modules] Error 2
make[2]: *** [Makefile:11: compile] Error 2
time: target/linux/compile#21.11#11.18#25.33
Error: Process completed with exit code 2.

hauke avatar May 09 '24 17:05 hauke

The more I look at this, the more I'm favoring simply deleting "generic" instead of merging it into "legacy". The reason being "generic" has too many settings appropriate for a mid-end machine. Merging it into "legacy" may well bloat "legacy" enough that it no longer runs on most legacy-class systems. Whereas most systems which want those settings can instead run "64".

About the only thing possibly appropriate to merge into "legacy" is the Xen support. Xen could be used on genuine legacy-class hardware.

I would keep the virtualization support for xen, kvm and hyperv. You can run the 32 bit system on a modern CPU in virtualization. This may be used for testing generic stuff. I think we can remove the EFI support. It is very uncommon.

hauke avatar May 09 '24 18:05 hauke

Please add a commit to remove CPU_CFLAGS_pentium4 from include/target.mk

hauke avatar May 09 '24 18:05 hauke