Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/33652 )
Change subject: arch/x86/acpi: Add os.asl ......................................................................
Patch Set 1:
Patch Set 1:
Isn't OS specific ACPI code discouraged? I mean I only know this from historians, but didn't we have this in the beginning of ACPI and it turned out very bad?
Yes, hence my negative review. My understanding of the matter is that testing for OS in ACPI is done to implement OS-specific workarounds.
Windows' implementation of the ACPI spec is rather... "weird". I don't know much about it, but I think Windows has a stable interface within versions, so that's why people writing ACPI code check for Windows versions. That does not necessarily mean these people are right, but who am I to judge? (I don't know about Windows internals)
OTOH, Linux does not have a stable interface. Let's suppose there's a check for Linux in some ACPI code to disable a specific PNP device that makes Linux crash. Let's also suppose Linux 3.4 fixes the issue. Checking for Linux matches *any* Linux, and a 2.6.11.1 kernel can behave very differently compared to a 5.2-rc5 kernel. Any newer kernel with the fix would still have that device disabled. And even if the check in ACPI was modified to check the Linux version, there are many distributions which use kernels with backported patches, so it would still fail on those.
And the above example assumes the firmware vendor actually tests stuff and issues updates, which unfortunately is not common. Linux documentation suggests using a _OSI("Linux-OEM-my_interface_name") query, to which the kernel will answer YES to when it has a fix for that bug. That also means the firmware does not need to be changed.