openwrt
openwrt copied to clipboard
kernel/x86: merge "generic" into "legacy"
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
Also please prepare patches for kernel 6.6 so that the PR is ready for commit https://github.com/openwrt/openwrt/pull/14868
There wouldn't be much difference. Simply duplicates everything for 6.6. If this got approved quickly it might go in before #14868.
The order of approval is still a mystery to me ;)
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).
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
?
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.
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.
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.
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.
Please add a commit to remove CPU_CFLAGS_pentium4
from include/target.mk