Linus Torvalds Comes Out Against "Completely Broken" x86_64 Feature Levels

[edxposed]

Just open htop when building the kernel and you'll see that -march doesn't work at all, kbuild adds a million -mno-* to counteract it.

[Britoid]

Where is CoC(k)?

Why is Linus still committing to the kernel? Oh, wait, without him everything will fall apart.

CoC is only for people whom have different opinions.

[Vermilion]

Linus: No issues writing non-portable code using custom GCC extensions outside C specs.
Also Linus: Who made these totally unofficial compiler targets that group some extensions together !!!1!

[trapexit]

I think he was again not in context. The micro architecture levels are an useful simplification to generate few optimized binaries. The kernel is not using this features. Other software is!

The statement isn't out of context. Those "useful simplifications" were suggested for Kconfig. https://lore.kernel.org/lkml/4a5898f....fastmail.com/ That's why he is commenting on it.

They should not be levels. They should be bespoke bundles of individually identifiable traits which {c,w}ould be discovered via CPUID et al or set manually. Levels require a strong contract of each new level being a superset of the last. If that is not true then they aren't levels and the naming is at best confusing. Not forgetting that as an earlier patch shows... not all features can/should/want to be used.

[jeisom]

This makes sense. Obviously getting a bunch of bug reports without fixes because of compiler bugs would be problematic. Especially from new users who don’t yet know what they are doing. We can apply the patch for more fine grain compiler options. Not really a big deal.

The compiler profiles also make sense for userspace where having tiers of hardware feature level are common across larger groups of users for distributions. We will see if v4 is ever useful as most of the added instructions are not very generic and mostly useful for very specific use cases.

[patrick1946]

The statement isn't out of context. Those "useful simplifications" were suggested for Kconfig. https://lore.kernel.org/lkml/4a5898f....fastmail.com/ That's why he is commenting on it.

They should not be levels. They should be bespoke bundles of individually identifiable traits which {c,w}ould be discovered via CPUID et al or set manually. Levels require a strong contract of each new level being a superset of the last. If that is not true then they aren't levels and the naming is at best confusing. Not forgetting that as an earlier patch shows... not all features can/should/want to be used.

Why should a new version a superset of the lower numbered? If you bring out a CPU which is not supporting that version you have to find an other. Mostly it will be older but it can be newer too. It is called deprecation.

[carewolf]

The statement isn't out of context. Those "useful simplifications" were suggested for Kconfig. https://lore.kernel.org/lkml/4a5898f....fastmail.com/ That's why he is commenting on it.

They should not be levels. They should be bespoke bundles of individually identifiable traits which {c,w}ould be discovered via CPUID et al or set manually. Levels require a strong contract of each new level being a superset of the last. If that is not true then they aren't levels and the naming is at best confusing. Not forgetting that as an earlier patch shows... not all features can/should/want to be used.

Well, of someone builds a generic kernels for a distro that only ships v2 or v3 binaries, it could make sense to configure the kernel to require a certain minimum and cut out support for older architectures.

[Gonk]

Actually v4 was useful until Intel could not get their little cores up to that level.

No, any attempt to support AVX-512 was doomed before Alder Lake's e-cores came along.

I'd love it if Zen 6 turned out to be a solid green row.

[spyke]

This model is used in many places, not only in glibc. For example, in Vulkan new extensions are added every week and then at some point in time a subset of new extensions is marked as mandatory and labelled as a new Vulkan version. So, instead of saying the kernel requires [a list of 354 x86 instuctions] you can simplify and say "our baseline is x86_v3".

[rene]

No one in the real world cares about obscure implementation details. Compiling for more advanced instructions available on newer processors = faster distro and faster software, it's really that simple. Linux can't be hamstrung by ancient hardware forever, that's what NetBSD is for.

actually many do, except planned obsolescence misguided new world order freaks - probably having $$$ job in big cooperations . The support is also there and works needs next to no work except an occasional api rename.