Hi BIOS! My Name Is “Linux”, Or Is It?
—-
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.
1. 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.
2. 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.
3. 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.
4. 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.
5. 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?
© Shantanu Goel | Hi BIOS! My Name Is “Linux”, Or Is It?—-
If you liked this post, then you can Subscribe to my feed
This post has 7 comments
August 5th, 2008
My only guess is that Windows does not support “capability checks” like that. Nor would they want to implement it when:
A) __OSI works fine for them
B) It helps Linux
“Bill Gates muses on the merits of making ACPI extentions “somehow Windows specific.”, continuing to say “If (sic) seems unfortunate if we do this work and get our partners to do the work and the result is that Linux works great without having to do the work.” In the same memo, he suggest defining “the APIs so that they work well with NT and not the others, even if they are open.”"
http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf
So basically it would be up to the BIOS manufacturers to do this specially for Linux.
August 5th, 2008
maccam, you are correct. But its so disgusting of bill to say that “we do this work…and result is that linux works great without having to do the work”. I mean, till now because of the crappy windows design linux has been doing ALL the work, and on top of that he talks of making it specially biased towards windows. I wonder what became of that case…
October 24th, 2008
The difference between Linux and Windows in this area is that if there is a problem with a motherboard/bios feature and Linux then Linux is likely to have a work around within a short amount of time. BIOS is firmware and should probably be replaced less often than an OS kernel, so this makes sense, but with Windows there aren’t the same fixes and the board producers are trying to work out of the box with versions of Windows rather than allowing all features.
Too bad BIOS and OS don’t negotiate on features; something similar to the LCP layer of PPP.
October 24th, 2008
Does anyone think that this is to disable functionality if the OS is not one that adheres to DRM standards.
October 24th, 2008
DRM was my first thought too. I’d suspect motherboard/bios makers of being in cahoots with Microsoft and using this “feature” to disable or reduce hardware functionality if a Microsoft-approve OS is not running the system.
October 24th, 2008
Ill give a link that explains the reasoning imo
http://www.custompc.co.uk/news/604521/foxconn-sabotages-bios-to-stop-linux-running.html
October 24th, 2008
Can someone tell me why the BIOS should care what OS is going to run? I thought it would be up to the OS to deal with whatever data the BIOS throws at it - as long as it standard driven.
Add a comment