A couple of days ago, I read this on Matthew Garrette’s blog, where he tells us about a vendor’s BIOS trying to figure out the OS type/version and setting things around on deciding the OS it is running. The call in question was _OSI(“Linux”). He goes on to say that the action the firmware takes, on finding out if the OS is linux, was probably inaccurate and it was good that linux kernel DOES NOT identify itself as “Linux” and returns false for the _OSI(“Linux”) and instead returns true when probed for Windows.
That got me thinking, the first thought being that isn’t this a BIG flaw in the kernel. I mean, trying to make the firmware aware of the OS and doing things accordingly is a good thing, right? Vendors can provide workarounds for OS flaws in this way. e.g. the thermal critical temperature event workaround that HP has for Windows Vista. If we are just emulating Vista here, then aren’t we inheriting their bugs as well? But “Never make judgements straightaway”, I have learnt in the past. So, thought about reading it a bit more. After some googling around, I came to know the sound reasoning behind the decision.
- Why not return true for _OSI(“Linux”)?
The difference between Linux and Windows is that the linux kernel is a continuously (and rapidly) moving target. When somebody probes for Windows 98 or Windows 2000 or Windows Vista, they can be sure about the behaviour, but Linux is too generic for us. The bug in one version of the kernel can be fixed in another one, and the behaviour changes, so one cannot rely on _OSI(“Linux”) as there is no generic/constant “Linux” interface.
- Why not then support _OSI(“Linux.xx.xx.xx”) or something equivalent to signify the kernel version?
This is also not reliable because which kernel would this be, the mainline, Ubuntu’s kernel, Fedora’s kernel, Suse’s kernel, or some user patched kernel? Moreover, the bugs fixed in later kernel versions are often backported to earlier versions by various distros. So, again one cannot rely on the kernel version as such, and there are just too many different kernel branches out there for a vendor to check against.
- Why to return true for something like _OS(“Windows 2006”)?
What I found out is that they do it because most vendors do most checks only if they find Windows and hence, it becomes a necessity to return true for this, for now.
- But what does that mean, is it always going to remain the same?
Basically, what the kernel guys want is a better usage of the _OSI strings. They want the BIOS developers to check for a “capability” rather than a platform or platform version. Because consistent behaviour might be expected when checked for a platform like Windows (Actually its a platform + its version because there are separate strings for Windows 98, Windows ME, Windows NT, Windows Vista, etc) because they are slow moving targets with major changes to ACPI behaviour done only with the next version of the OS that is released after many years, but this is not true for faster targets like linux where changes happen often and can even be backported. So, essentially the situation will remain the same until vendors straighten out their code.
- But is it justified for the linux developers/users to expect this to be followed by the vendors?
This is a tough question with no straight answer. Even though linux users are in minority but still they are significant in number, and if they pay the same money for the hardware as their windows counterparts, they should get the same level of firmware support as well. However, that said, it is also true that the vendors have to draw the line somewhere and given the rapidly changing behaviour of the kernel they cannot always be expected to keep up, especially with all the costs involved. Thats why the kernel community wants them to be aware of these inherent flaws in their design and move to a system (check for capability, not for platform) where they don’t have to “keep up” anymore. And meanwhile they absorb the strain into the kernel/drivers, emulating as Windows, and trying to make the workarounds for Windows bugs in their code instead. And they have started efforts to make the vendors aware of this linux peculiarity and are trying to document the linux behaviour
Reading material: Thomas Renninger wrote this doc” ACPI BIOS Guideline For Linux.
I’m convinced with the reasoning. But as always, one man cannot look at all the angles and I might have missed the one that makes this all junk. Are you convinced too? Or do you have any other angle to provide?