On 23 Jun 2021 17:04:27 +0200, Florian Weimer wrote: > We have an interface in glibc to query CPU features: > X86-specific Facilities > <https://www.gnu.org/software/libc/manual/html_node/X86.html> > > CPU_FEATURE_USABLE all preconditions for a feature are met, > HAS_CPU_FEATURE means it's in silicon but possibly dormant. > CPU_FEATURE_USABLE is supposed to look at XCR0, AT_HWCAP2 etc. before > enabling the relevant bit (so it cannot pass through any unknown bits). It's a nice initiative, but it doesn't help library and applications that need to be either cross-platform or backwards compatible. The first problem is the cross-platformness need. Because we library and application developers need to support other OSes, we'll need to deploy our own CPUID-based detection. It's far better to use common code everywhere, where one developer working on Linux can fix bugs in FreeBSD, macOS or Windows or any of the permutations. Every platform-specific deviation adds to maintenance requirements and is a source of potential latent bugs, now or in the future due to refactoring. That is why doing everything in the form of instructions would be far better and easier, rather than system calls. [Unless said system calls were standardised and actually deployed. Making this a cross-platform library that is not part of libc would be a major step in that direction] The second problem is going to be backwards compatibility. Applications and libraries may want to ship precompiled binaries that make use of the new CPU features, whether they are open source or not. It comes as no surprise to anyone that we CPU makers will have made software that use those features and want to have it ready on Day 1 of the HW being available for the market (if we're doing our jobs right). That often involves precompiling because everyone who installed their compilers more than one year ago will not have the necessary tools to build. That runs counter to the need to use a libc interface that didn't exist until recently. And by "recently", I mean "anything since the glibc that came with Red Hat Enterprise Linux 7" (2.17). So no, application and library developers will not use libc functions they don't need to, especially if it adds to their problems, unless there's no way around it. > Previously kernel developers have expressed dismay that we didn't > coordinate the interface with them. This is why I want raise this now. You also need to coordinate with your users. A platform-specific API to solve a problem that is already solved is "knock yourself out, we're not going to use this." So my first suggestion is to remove the "platform-specific" part and make this a cross-platform solution. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering
