Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Fri, 2008-02-22 at 18:10 +, Matthew Garrett wrote: On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote: So to what Windows version are we compatible? Microsoft has been very good at keeping backwards compatibility for this functionality, so the obvious aim is to be compatible with the current version of Windows and all previous versions. If necessary, we can switch to compatibility modes depending on whether the firmware requests XP or Vista or whatever. Do you want to remove lower versions at some time? No. What about Longhorn or whatever coming up? We aim to be compatible with it. You want to be compatible with all Windowses that exist and ever will get published? Impossible! Then these strings might branch into a server and a workstation Windows, to which one do you want to stay compatible, both again? Whichever one the firmware asks for. All this does not make sense and it does not work. It makes perfect sense and I've no reason to think it doesn't work. All this is an advantage for vendors who do not care about Linux, but it makes life really hard for vendors who want to support it. No! We have the choice between providing a benefit to a subset of vendors at the cost of never being able to fix bugs, or just making everything work. Given the choice between making everything work and making Lenovo work, I'll go for making everything work. But you will fail for sure. It is so realistic like: We aim to be compatible with all Windows versions that ever existed. Supporting the one and the other version can and in reality is mutually exclusive. The _OSI interface is not thought for Linux kernel developers to stay compatible with Windows. It got invented for vendors being able to provide hot-fixes for their BIOS for Operating Systems they are willing to support. No! _OSI is (according to the spec) there to enable vendors to support *features* provided by specific OSs, not to work around bugs in that OS. What does an _OSI of Linux mean? We don't have a well-defined feature set. We don't have a stable set of bugs. Our development model is inherently different from Windows, and providing this information just makes no sense. Invented was wrong. After spec it indeed has another meaning, but you unfortunately are right with: Microsoft defines the standards by their implementations. In this case it probably were the vendors who need this hook asking Microsoft to provide it (and we remove it for Linux...). It is used by vendors being able to provide hot-fixes for their BIOS for Operating Systems they are willing to support. Please go through through some OSI declarations. I've done it (see at the end), I just went through some for 20 minutes to get a bit of an impression what kind of features and what kind of hacks have been added. And I could only identify hacks (needs more evaluating, as soon as more complicated functions are invoked it's getting difficult). So you do not try to be feature, but bug compatible with all kind of Windows versions. I agree it made sense some years ago, when it was not clear for what _OSI is/will get used by vendors and Microsoft, but now it leads to a totally undefined behavior and confusion. While _OSI(xy) can return true for several strings, current BIOSes rely on the fact that only one Windows OS string returns true, e.g. Windows 2001 SP1. For most it fortunately does not matter as they all override one variable to store the information. But not all! E.g. all ThinkPads seem to store this in different values: \WNTF (Windows NT), \WXPF (Windows XP), \WSPV (Window XP Service Pack version), \WVIS (Vista), \WMEF (Millenium Edition), \W98F (98). And they add different BIOS workarounds/hacks. The BIOS developers rely on that only either of these are set (or WXPF + Service Pack variable). So returning true for all kind of Windows Versions is a really bad idea and we should move away from this asap. Also removing old ones and switch to a new Version if a new one is used (e.g. remove Windows 2006 and switch to Windows Longhorn as soon as it is available) does not make sense. The problem is that _OSI is not used for features, but for BIOS fixes. I expect it works like that: It seems all kind of ASL templates are copied together to a BIOS, and made work as they should. Then OSI hooks are added for all Windows OS it should support. Later at a specific time of their product (when QA is heavily testing each OS), they are able to only add hot-fixes for a specific OS (if only a specific OS is affected) without the need of revalidating whether other OSes are still running fine. Len, can you put the acpidumps you received on a public ftp server, pls. This should make it easy for others to reproduce or invalidate my findings. IMO there is only one long term solution: Start removing old OSI strings returning true (all but Windows 2006). This should be no functional change on most machines.
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote: Let's look at this differently. Most hardware is produced by vendors who don't care about Linux. We need to make that hardware work anyway. The only way we can achieve that is to be bug-compatible with Windows. Therefore, any way in which Linux behaviour varies from Windows behaviour is a bug. The only reason to export any indication that the kernel is Linux is because our behaviour is not identical to Windows. But, given that that's a bug, the solution should be to fix Linux and not to encourage vendors to put workarounds in their firmware. So to what Windows version are we compatible? We currently return true for Windows 2006. According to drivers/acpi/utilities/uteval.c we return true for all of these: Windows 2000, /* Windows 2000 */ Windows 2001, /* Windows XP */ Windows 2001 SP1, /* Windows XP SP1 */ Windows 2001 SP2, /* Windows XP SP2 */ Windows 2001.1, /* Windows Server 2003 */ Windows 2001.1 SP1, /* Windows Server 2003 SP1 - Added 03/2006 */ Windows 2006, /* Windows Vista - Added 03/2006 */ Stuff added for Windows 2001 SP2 might break Windows 2006. How do you want to handle this? Do you want to remove lower versions at some time? What about Longhorn or whatever coming up? Then these strings might branch into a server and a workstation Windows, to which one do you want to stay compatible, both again? All this does not make sense and it does not work. All this is an advantage for vendors who do not care about Linux, but it makes life really hard for vendors who want to support it. The _OSI interface is not thought for Linux kernel developers to stay compatible with Windows. It got invented for vendors being able to provide hot-fixes for their BIOS for Operating Systems they are willing to support. So what should a vendor do if he has a BIOS hotfix for Windows 2003 only. The fix workarounds an old W2003 AML bug. But this fix will break Linux and Vista on his machine. For Vista he can take care, Linux will break. And you are going to try to implement a workaround for an old W2003 OS bug (after people got angry because their machine they bought with Linux pre-loaded does not boot anymore after a BIOS update)... Your scenario only makes sense for Windows 2006 vendor fixes but also these are outdated soon, all this simply does not work... Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Fri, Feb 22, 2008 at 03:07:42PM +0100, Thomas Renninger wrote: So to what Windows version are we compatible? Microsoft has been very good at keeping backwards compatibility for this functionality, so the obvious aim is to be compatible with the current version of Windows and all previous versions. If necessary, we can switch to compatibility modes depending on whether the firmware requests XP or Vista or whatever. Do you want to remove lower versions at some time? No. What about Longhorn or whatever coming up? We aim to be compatible with it. Then these strings might branch into a server and a workstation Windows, to which one do you want to stay compatible, both again? Whichever one the firmware asks for. All this does not make sense and it does not work. It makes perfect sense and I've no reason to think it doesn't work. All this is an advantage for vendors who do not care about Linux, but it makes life really hard for vendors who want to support it. No! We have the choice between providing a benefit to a subset of vendors at the cost of never being able to fix bugs, or just making everything work. Given the choice between making everything work and making Lenovo work, I'll go for making everything work. The _OSI interface is not thought for Linux kernel developers to stay compatible with Windows. It got invented for vendors being able to provide hot-fixes for their BIOS for Operating Systems they are willing to support. No! _OSI is (according to the spec) there to enable vendors to support *features* provided by specific OSs, not to work around bugs in that OS. What does an _OSI of Linux mean? We don't have a well-defined feature set. We don't have a stable set of bugs. Our development model is inherently different from Windows, and providing this information just makes no sense. So what should a vendor do if he has a BIOS hotfix for Windows 2003 only. The fix workarounds an old W2003 AML bug. But this fix will break Linux and Vista on his machine. For Vista he can take care, Linux will break. And you are going to try to implement a workaround for an old W2003 OS bug (after people got angry because their machine they bought with Linux pre-loaded does not boot anymore after a BIOS update)... Fine. So we define different behaviour depending on whether the firmware asks for Vista or not. This isn't rocket science. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thursday 21 February 2008 12:15, Theodore Tso wrote: On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote: OEMs that really want to modify the BIOS to recognize OS interfaces that are in Linux should propose new OSI strings that specify interfaces, not broad categories of operating sytems; and in Linux we shoudl use, or not use, those strings, as appropriate. I've recently been in discussion with OEMs on exactly this topic -- I'm sorry it didn't happen a year ago. So you mean SLED 10 SP2, UBUNTU supported version XY strings? No, no, no, no, no! What part of specify interfaces, not broad category of operating sytems didn't you understand? So for example, if we if some vendor decides for some silly reason that they must the Nvidia graphics chipsets, and Nvidia is the one holdout which is lame about providing information so we can program the video hardware correctly after a suspend/resume, maybe there is a feature flag, OSI(LameNvidiaSuspendResume). The suppose 6 months later, someone manages to disassemble the Nvidia driver in some legal jurisdiction where there is no DMCA nonsense, and so Linux is now capable of dealing with the video card itself. Now future kernels can simply omit that very specific OSI string. Just because we are saying that OSI(Linux) is bad, does not mean that people are saying that OSI(SLED 10 SP2) is the right answer. Hell, no! The right thing is something like OSI(LameNvidiaSusependResume). Ted speaks the truth. Indeed, this is exactly the issue with the Dell M4300. Dell executes BIOS re-post on OSI(Linux) for the benefit of text-mode video restore, and for the case where nv is used instead of the binary nvidia driver that knows how to do this. Why is that bad? Well, consider why Dell doesn't execute that BIOS code unconditionally... It is because it would make Windows resume speed uncompetitive. So when Linux nv gets fixed (like i915 was) so that it can restore video w/o the BIOS, how to you un-do the damage? With OSI(Linux) you can't -- Linux will be at a permanent disadvantage to Windows on that platform _forever_. However, if nv were changed to call an I/F in Linux/ACPI that says please add OSI(LameNvidiaSusependResume) and Dell's BIOS executed the video BIOS restore only when that was set, then a future smarter nv could stop using that crutch and Linux would no longer be at a disadvantage. -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Thomas, Thanks for the note. Please read the messages on linux-acpi with dmi in the subject for some background. yes, OSI(Linux) was enabled by default through 2.6.22 and was disabled by default starting in 2.6.23. The reason it has come up recently is because it got into a reference BIOS -- and I'm sorry to admit that I was a party to that -- I wasn't thinking. Tomas Carnecky's reply is 100% correct. We can't support OSI(Linux) any more than we could support _OS=Linux, or Microsoft could support OSI(Windows) -- particularly on an OS that changes as fast as Linux does. To do so would in some cases put Linux at a permanent disadvantage to competing operating systems. Yes, we are attempting to close Pandora's box. I think we'll be successful, though we have to handle the Dell and Lenovo systems which actually use OSI(Linux) on purpose. Everybody else appears to be using it by mistake, sometimes with no effect, sometimes with negative effect. No, the DMI list is not large, it is mostly comments and it is __init. I _strongly_ urge you to not fork from the .stable and mainline kernel in this area. OEMs that really want to modify the BIOS to recognize OS interfaces that are in Linux should propose new OSI strings that specify interfaces, not broad categories of operating sytems; and in Linux we shoudl use, or not use, those strings, as appropriate. I've recently been in discussion with OEMs on exactly this topic -- I'm sorry it didn't happen a year ago. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 12:13:24AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Feb 2008, Matthew Garrett wrote: It doesn't punish them. They're the ones who are going to work with us to ensure that Linux works on their hardware, and their needs are going And since when we have to work exactly like Windows (whatever version) does in THAT case? Also, why would one thing (proper replacement for OSI(Linux)) cause any sort of difference over the other (trying to be bug-to-bug compatible with Microsoft crap). Offering OSI(Linux) makes a statement about our implementation - we're telling the firmware that it behaves in a certain way. That lets vendors start depending on that behaviour, and if that behaviour turns out to be different to Windows then we never get to fix that behaviour. Fine for vendors that have special-cased their firmware, bad for the vast majority of systems. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 09:15:32AM +, Matthew Garrett wrote: Offering OSI(Linux) makes a statement about our implementation - we're telling the firmware that it behaves in a certain way. That lets vendors start depending on that behaviour, and if that behaviour turns out to be different to Windows then we never get to fix that behaviour. Fine for vendors that have special-cased their firmware, bad for the vast majority of systems. Exactly, that's the problem. Suppose we put in an OSI(Linux), and Lenovo, thanks to the fact that they are working with Novell, puts in a special case hack just for whatever version of SLES they happen to be testing with. Well, great. Now suppose that three other laptops from different manufacturers (say, Sony, Fujitsu, and Asus) do things differently, the Windows way, and someone posts a patch to the ACPI drivers (and it might not and probably won't be the Thinkpad specific thinkpad_acpi.c file) which changes things so that it works for Sony, Fujitsu, et. al. --- and in the process, it breaks things for Lenovo, because the Lenovo is doing something special based on OSI(Linux) thanks to their special collaboration with Thomas Renniger and Novell. Oops. Now we have a mess, and we have to start having special DMI-based blacklists and whitelists, and life generally sucks. It would be much better if we define feature-specific OSI() strings that have well defined meanings for each place where Lenovo has to do something different than What Happens With Windows --- especially for stuff which is generic, since all laptop manufactuers need to interoperate with whatever cr*p Windows ship. At the end of the day, since Intel was originally too lazy to ship an ACPI conformance test suite, like it or not, Windows *has* become the APCI conformance test suite, and all laptop manufacturers (at least for today) must bow to the might and power which is the market share of Microsoft. - Ted - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote: It would be much better if we define feature-specific OSI() strings that have well defined meanings for each place where Lenovo has to do something different than What Happens With Windows --- especially for stuff which is generic, since all laptop manufactuers need to interoperate with whatever cr*p Windows ship. At the end of the day, since Intel was originally too lazy to ship an ACPI conformance test suite, like it or not, Windows *has* become the APCI conformance test suite, and all laptop manufacturers (at least for today) must bow to the might and power which is the market share of Microsoft. My concern with this is that until we know where we deviate from the Windows behaviour, we don't know what strings we'd need to provide. And once we *do* know where we deviate, we should fix that deviation rather than provide an identifying string. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote: How about WMI? Do you think that there will be some point in the future, when we could claim that our WMI implementation is the same as Windows + HW manufacturer private driver? When vendors require custom drivers, we're going to end up requiring a custom driver. That's true regardless of how the functionality is exposed. The solution there is to encourage vendors not to require custom drivers, not to get them to expose the same functionality in two different ways. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Matthew Garrett wrote: On Thu, Feb 21, 2008 at 08:51:32AM -0500, Theodore Tso wrote: It would be much better if we define feature-specific OSI() strings that have well defined meanings for each place where Lenovo has to do something different than What Happens With Windows --- especially for stuff which is generic, since all laptop manufactuers need to interoperate with whatever cr*p Windows ship. At the end of the day, since Intel was originally too lazy to ship an ACPI conformance test suite, like it or not, Windows *has* become the APCI conformance test suite, and all laptop manufacturers (at least for today) must bow to the might and power which is the market share of Microsoft. My concern with this is that until we know where we deviate from the Windows behaviour, we don't know what strings we'd need to provide. And once we *do* know where we deviate, we should fix that deviation rather than provide an identifying string. How about WMI? Do you think that there will be some point in the future, when we could claim that our WMI implementation is the same as Windows + HW manufacturer private driver? Regards, Alex. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Matthew Garrett wrote: On Thu, Feb 21, 2008 at 05:48:33PM +0300, Alexey Starikovskiy wrote: How about WMI? Do you think that there will be some point in the future, when we could claim that our WMI implementation is the same as Windows + HW manufacturer private driver? When vendors require custom drivers, we're going to end up requiring a custom driver. That's true regardless of how the functionality is exposed. The solution there is to encourage vendors not to require custom drivers, not to get them to expose the same functionality in two different ways. It will always be two ways -- Windows way with WMI and other OSes way without it. The choice is there to place this non-Windows custom driver -- in C or in AML. This is their choice, right? If they choose to not create custom driver or have some concerns about complexity of its implementation in C rather than in AML, they should be allowed to choose AML. - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thursday 21 February 2008 09:41:13 you wrote: Thomas, Thanks for the note. Please read the messages on linux-acpi with dmi in the subject for some background. Can you be a bit more specific. Grepping for dmi is a bit verbose on the linux-acpi list. yes, OSI(Linux) was enabled by default through 2.6.22 and was disabled by default starting in 2.6.23. The reason it has come up recently is because it got into a reference BIOS -- and I'm sorry to admit that I was a party to that -- I wasn't thinking. Tomas Carnecky's reply is 100% correct. We can't support OSI(Linux) any more than we could support _OS=Linux, or Microsoft could support OSI(Windows) -- particularly on an OS that changes as fast as Linux does. To do so would in some cases put Linux at a permanent disadvantage to competing operating systems. No, not providing an interface at all is a disadvantage, a permanent one. You all look at this too much from the kernel point of view: You are a vendor and you want to provide a BIOS update, because on the model you sold with Linux on it, there is a bug. For some reason Linux is not 100% compatible to Windows and the bug does only exist on Linux. But you still have to support Windows on that machine and unfortunately this machine got sold with Windows 10x more often than with Linux. The bug is rather complicated to fix/workaround through the OS (E.g. suspend reordering, AML bug, you simply misread the ACPI spec and it did work for Windows (the ACPI kernel maintainer likes to add the compatibility hack, but it's just too intrusive to backport into your stable kernel release you support), ...). But a modification in the DSDT is a one-liner and an obvious fix. You desperately search for a flag to be able to make sure you do not risk to break Windows... Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad for us (yet another complex Windows compatibility hack). Yes, we are attempting to close Pandora's box. Too late and IMO there is nothing bad about it. I think we'll be successful, though we have to handle the Dell and Lenovo systems which actually use OSI(Linux) on purpose. Everybody else appears to be using it by mistake, sometimes with no effect, sometimes with negative effect. Are you sure, they use it by mistake? Again, think from a vendor's point of view... What I expect happened here: Vendors thought about better Linux support. Some already chose a distribution which (most common should be Ubuntu here, It's Dell, already Acer? and others?) They pre-load it with a specific, probably a rather stable release and sell their laptops with it. And they have to provide support for it, at least for the release they sold it with. I expect the first thing they did when thinking about Linux support is that they added something similar like: Name (Linx, 0) ... if (_OSI(Linux)) Store(1, Linx) to their BIOSes, the same they do for Windows'es they have to support. They even may have verified it working... the NOP. Now if there pop up problems, they can and will use this to provide Linux specific BIOS fixes with code that is only processed on Linux, because they cannot risk to break Windows. If you rip this out now you will see: - white/black listed NOPs that break after a BIOS update with later kernels - No BIOS updates for Linux at all in this area (and this is what I mean with permanent disadvantage) No, the DMI list is not large, It is very confusing. it is mostly comments and it is __init. That is not really important. I _strongly_ urge you to not fork from the .stable and mainline kernel in this area. Matthew's arguments are quite interesting. I still disagree with: - simply ripping it out (at least do it soft) - Remove all possibilities for vendors who want support Linux to provide safe, only Linux affecting BIOS updates, just for the sake of being Windows compatible The strongest argument: I agree that they of course should contribute their code and start working on the kernel, provide software updates etc. But those guys do not have to share much, anyway: (Some guessing now): Asus, Acer, Lenovo, Dell,...: have to make sure that they buy and put hardware into their machines from companies that work on Linux now. This is where we will see most advantages. They do not manufacture most HW components themselves (network/wlan/sound/... cards). They manufacture or at least have direct control over their BIOS, though. So this kind of hot-fix is most convenient for them (or may be the only possibility for them). OEMs that really want to modify the BIOS to recognize OS interfaces that are in Linux should propose new OSI strings that specify interfaces, not broad categories of operating sytems; and in Linux we shoudl use, or not use, those strings, as appropriate. I've recently been in discussion with OEMs on exactly this topic -- I'm sorry it didn't happen a year ago. So you mean SLED 10 SP2,
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, 21 Feb 2008, Sergio Monteiro Basto wrote: On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Feb 2008, Matthew Garrett wrote: It doesn't punish them. They're the ones who are going to work with us to ensure that Linux works on their hardware, and their needs are going And since when we have to work exactly like Windows (whatever version) does in THAT case? Also, why would one thing (proper replacement for OSI(Linux)) cause any sort of difference over the other (trying to be bug-to-bug compatible with Microsoft crap). I agree with Henrique. Since we have, in fact, more Windows cases than Linux cases and for Linux, just announce that is recommended, osi=linux. EH? I am *against* osi=Linux. I am for a proper *replacement* for OSI=Linux, *and* trying to be Windows-compatible where possible. Also it is possible put Linuxs bios in a kind of white-list in kernel code ... Linux-BIOS boxes *really* should not need ACPI for anything other than the very basic stuff, at all. Nor should them implement SMM handling, or any other such crap that always bite us back in the nether regions, with poisoined teeth. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, Feb 21, 2008 at 04:41:21PM +0100, Thomas Renninger wrote: The bug is rather complicated to fix/workaround through the OS (E.g. suspend reordering, AML bug, you simply misread the ACPI spec and it did work for Windows (the ACPI kernel maintainer likes to add the compatibility hack, but it's just too intrusive to backport into your stable kernel release you support), ...). But a modification in the DSDT is a one-liner and an obvious fix. You desperately search for a flag to be able to make sure you do not risk to break Windows... Now they have to ignore the bug. Bad for the vendor, bad for the customer, bad for us (yet another complex Windows compatibility hack). And then later we fix the bug and the Linux workaround starts breaking things. The vendor is unhappy. You can't even just key it off kernel versions, since distributions will backport arbitrarily large chunks of code (and if you doubt this, take a look at the sata tree in the RHEL kernel some time). A general Linux flag is the way to start, everything more specific will/can get embedded into this flag later if it makes sense (without any risk for the vendors to break Windows). There are (I expect most) cases where embedding stuff into if(linux) makes a lot sense. But Henrique and others are probably right that we need something more fine grained later (in rare cases, e.g. the in-kernel graphics driver issues). There's no flag we can provide to indicate a desire for graphics POSTing. If vendors want to offer that, then they should provide an entry point that triggers it and a kernel driver that calls it. The policy for deciding whether or not to do this is far more complex than can be provided in-kernel. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
Thomas Renninger wrote: Hi, please correct me if I am wrong or missed something: osi=linux was an ability for vendors to provide Linux specific BIOS updates/quirks. _OSI(Linux) returned true until kernel version 2.6.23 (included?). This has been replaced by rather huge black+white lists (at least they most probably will grow huge) to get rid of it again. Goal is to not return _OSI(Linux) as Intel identified it (after inventing it? Doesn't really matter...) as not the right thing to do as it does not consider fixes that might show up in specific kernel versions in the future. This is the only reason I found, did I miss one or the other? Linux is way too generic. The kernels is such fast moving target that changes with every other version. The idea is to replace _OSI(Linux) with _OSI(Needs video POST after resume) etc. To allow the BIOS to figure out what _exactly_ it needs to do, rather then guessing based on the kernels version etc. A lot has been discussed in linux-acpi, though mostly hidden in related threads. Ask Henrique, he's been trying to come up with a proper _OSI() interface. See for example this thread: http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg12262.html The idea to remove _OSI(Linux) it to get the hardware vendors to stop using it _now_, we don't want them to use it any longer. It will take some time to come up with a proper interface, but at least we'll have less legacy to deal with. Some questions and suggestions: Is there already a replacement or will there pop up something soon, which I may have missed? This is an interface to the outside world (out of the kernel... in this case not to userspace via /proc /sys ioctl, but to the BIOS). Such interfaces should have a very long lifetime, once they are implemented. In this case it should have an even much longer life time than any /sys or whatever userspace interface. Telling vendors that this will vanish and giving them time to remove it from their BIOSes or better replace it with something else is the way to go here IMO. The current policy is to just return zero on _OSI(Linux). I don't get it why you do this. You break machines on purpose. Machines were vendors possibly have invested time to improve them for Linux. Why don't you just announce it, write it down in Documentation, also write it to dmesg, instead of pls send acpidump to acpi list, something like: osi=linux is deprecated and will get removed (ok there popped up a way too much of these, but maybe dmiblacklist the message, don't do any functional change for now...). Maybe that just didn't get outside of the linux-acpi mailinglist, but that that _OSI(Linux) is deprecated has been known for some time now. But you are right, it was never publicly announced. First users were asked to try acpi_osi=!Linux (sometime in the .23/.24 timeframe?)and see if it works better. Now !Linux is default, and they are asked to try acpi_osi=Linux so that we can fill the blacklist. Why shouldn't I remove the whole dmi black/white listing from our OpenSUSE kernel and return true for _OSI(Linux), this probably fixes a lot machines and avoids bug reports (and annoyed users). I plan to do this rather soon if I don't get some good arguments. IMO this should also be done mainline. It is a pity that 2.6.24 now has this. IMO this should even go back to a 2.6.24.X stable kernel. Just let it in and announce to not use it and provide something else (this has time then...). --- Here a suggestion for an enhanced Linux Operation System Identification interface for ACPI: For general BIOS hot-fixes a check for osi=linux is sufficient for vendors and allows them to provide a fix without risking breakage of their Windows OS. This one should stay. No, it's not sufficient, it's useless. Linux - what should that stand for? How should the BIOS vendors interpret it? It's totally ambiguous. It was removed, and should stay removed. BIOS can do _OSI(Windows 2006) because Windows 2006 defines a non-moving target. MS will not change how Vista behaves without changing the string (they sometimes update the string in service packs). The problem is you do not know in what kernel version this might get fixed at the time the BIOS is published with the short term workaround. While this knob is essential for vendors for pre-loads, it might break the machine if the user is trying to install a newer Linux distribution with a newer Kernel where the problem got fixed. Then the workaround might even slow down or break the system... An example: Lenovo wants to get rid of brightness switching via their old method (int10?). But this needs in-kernel graphics driver support for Intel graphics cards. Therefore ibm_acpi currently simulates this, the specified ACPI brightness interface cannot be used. In which kernel version in-kernel graphics drivers will be supported and Lenovo can safely throw out int10 brightness switching from their BIOSes is not known yet. I
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, 20 Feb 2008, Tomas Carnecky wrote: A lot has been discussed in linux-acpi, though mostly hidden in related threads. Ask Henrique, he's been trying to come up with a proper _OSI() interface. See for example this thread: No, I haven't. Len is the mastermind behind it, AFAIK. I am just one of the interested parties. I have been burned by halfway-done jobs in the kernel once-too-many already IMO, so I am sticking around the threads to make sure THIS time, at least I will also be at fault if it is done wrong. The fact that Lenovo (and therefore, ThinkPads) is one of the vendors directly affected by OSI(Linux) issues, has a LOT to do with my continued participation on this issue, too. The saner the ThinkPad firmware is, from a Linux standpoint, the better for me. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, 2008-02-20 at 11:31 +0100, Tomas Carnecky wrote: Thomas Renninger wrote: Hi, please correct me if I am wrong or missed something: osi=linux was an ability for vendors to provide Linux specific BIOS updates/quirks. _OSI(Linux) returned true until kernel version 2.6.23 (included?). This has been replaced by rather huge black+white lists (at least they most probably will grow huge) to get rid of it again. Goal is to not return _OSI(Linux) as Intel identified it (after inventing it? Doesn't really matter...) as not the right thing to do as it does not consider fixes that might show up in specific kernel versions in the future. This is the only reason I found, did I miss one or the other? Linux is way too generic. The kernels is such fast moving target that changes with every other version. The idea is to replace _OSI(Linux) with _OSI(Needs video POST after resume) etc. To allow the BIOS to figure out what _exactly_ it needs to do, rather then guessing based on the kernels version etc. Ok, I see the point and I agree that kernel versions only is a bit problematic. I still like it, because it seem to me the only way that is a bit generic. So the suggestion is to introduce very specific strings (hopefully not much) for specific milestones/patches similar to Windows 2006 SP1 we might have a in-kernel graphics, but this hopefully will be the only one... The string(s) are listed on acpi.sourceforge.com? Hmm, not sure whether this is such a perfect idea or could work at all, maybe for very extrem/huge changes. But that is not enough. There is nothing wrong with giving the vendors the possibility to check whether they are running on Linux. Document the problem of future kernel versions for vendors. I expect most of the if(linux) AML fixups from vendors make very much sense to keep them forever. For all the stuff like: Windows likes to have it this way, it violates all kinds of specifications for it, so for Linux we do it right and provide a proper interface. There are dozens of more arguments.. A lot has been discussed in linux-acpi, though mostly hidden in related threads. Ask Henrique, he's been trying to come up with a proper _OSI() interface. See for example this thread: http://www.mail-archive.com/linux-acpi@vger.kernel.org/msg12262.html The idea to remove _OSI(Linux) it to get the hardware vendors to stop using it _now_, we don't want them to use it any longer. It will take some time to come up with a proper interface, but at least we'll have less legacy to deal with. Some questions and suggestions: Is there already a replacement or will there pop up something soon, which I may have missed? This is an interface to the outside world (out of the kernel... in this case not to userspace via /proc /sys ioctl, but to the BIOS). Such interfaces should have a very long lifetime, once they are implemented. In this case it should have an even much longer life time than any /sys or whatever userspace interface. Telling vendors that this will vanish and giving them time to remove it from their BIOSes or better replace it with something else is the way to go here IMO. The current policy is to just return zero on _OSI(Linux). I don't get it why you do this. You break machines on purpose. Machines were vendors possibly have invested time to improve them for Linux. Why don't you just announce it, write it down in Documentation, also write it to dmesg, instead of pls send acpidump to acpi list, something like: osi=linux is deprecated and will get removed (ok there popped up a way too much of these, but maybe dmiblacklist the message, don't do any functional change for now...). Maybe that just didn't get outside of the linux-acpi mailinglist, but that that _OSI(Linux) is deprecated has been known for some time now. But you are right, it was never publicly announced. First users were asked to try acpi_osi=!Linux (sometime in the .23/.24 timeframe?)and see if it works better. Now !Linux is default, and they are asked to try acpi_osi=Linux so that we can fill the blacklist. It is not working like that! You cannot provide an important interface. Then realize that it is not exactly what it was intended for and just rip it out. While modifying sysfs and procfs without announcing must not happen, it is by far not that bad. Just keep it, tell the vendors that they should not use it, put in ugly messages if they do (if you like black/white list the message...). If this really should vanish, what is IMO a really bad idea. But do not just remove it! Why shouldn't I remove the whole dmi black/white listing from our OpenSUSE kernel and return true for _OSI(Linux), this probably fixes a lot machines and avoids bug reports (and annoyed users). I plan to do this rather soon if I don't get some good arguments. IMO this should also be done mainline. It is a pity that 2.6.24 now has this.
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, 20 Feb 2008, Matthew Garrett wrote: Let's look at this differently. Most hardware is produced by vendors who don't care about Linux. We need to make that hardware work anyway. The only way we can achieve that is to be bug-compatible with Windows. Therefore, any way in which Linux behaviour varies from Windows behaviour is a bug. The only reason to export any indication that the kernel is Linux is because our behaviour is not identical to Windows. But, given that that's a bug, the solution should be to fix Linux and not to encourage vendors to put workarounds in their firmware. That punishes vendors which actually care about Linux. These are quite rare in the laptop and desktop market, but they do exist. And such vendors are quite *common* in the enterprise hardware market which doesn't run Windows. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote: Let's look at this differently. Most hardware is produced by vendors who don't care about Linux. We need to make that hardware work anyway. Not really. If you buy machine noname XY, you have to face the fact that HW may not work on Linux correctly. You can try fix to it, but you cannot write a driver for WLAN card from vendor noname and card reader from never heard of that company. If you buy the wrong graphics card you may end up without 3D and whatever else cool features the card supports. So at least since HP, Dell, Lenovo (also Acer?) are selling pre-loaded Linux laptops, you should be smart enough to take such a thing where the BIOS is adjusted to run on Linux or you pretty much have to reckon with trouble. So being Windows compatible is nice, but sticking to specifications is more important (we are far away from and never will be Windows compatibility in WMI implementation right?). Imagine a vendor using if(linux) provides as a whole SSDT with all the fan and thermal implementations perfectly fit to the ACPI specification and therefore stick to the Linux kernel implementations? Next point is that if vendors pre-load their model with a specific distribution, they need such a knob. Please do not think about what happens when I upgrade to the latest kernel (which should still be no problem when they know how to use this). Think about how these vendors should fix a complex Linux bug via a BIOS hot-fix update ... Think about a functional change they have to implement in their BIOS for a Windows Vista SPX change. While the machine may still run fine with the latest mainline kernel, the kernel they have to provide support for will break. I see the problem with this scenario, but try to think from Dell's/HP's/... point of view. They want to have such a thing. The only way we can achieve that is to be bug-compatible with Windows. Therefore, any way in which Linux behaviour varies from Windows behaviour is a bug. The only reason to export any indication that the kernel is Linux is because our behaviour is not identical to Windows. Linux behaviour is not identical to Windows, never will be and after vendors start pre-loading also do not need to be... But, given that that's a bug, the solution should be to fix Linux and not to encourage vendors to put workarounds in their firmware. I see it the other way round. Encourage vendors to fix their BIOSes, instead of putting Windows compatibility workarounds into the kernel. Thomas - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, Feb 20, 2008 at 07:21:57PM +0100, Thomas Renninger wrote: On Wed, 2008-02-20 at 17:32 +, Matthew Garrett wrote: Let's look at this differently. Most hardware is produced by vendors who don't care about Linux. We need to make that hardware work anyway. Not really. If you buy machine noname XY, you have to face the fact that HW may not work on Linux correctly. No. You have failed. Do not pass go. You can try fix to it, but you cannot write a driver for WLAN card from vendor noname and card reader from never heard of that company. If you buy the wrong graphics card you may end up without 3D and whatever else cool features the card supports. That's fine. Some hardware support is difficult. Some hardware support is not difficult. The only possible situation in which exporting some sort of OSI value for Linux is helpful is when the firmware authors know what the difference between the Linux and Windows behaviours are. If we know that, we can fix it. Fixing it not only fixes the machine in question, it probably fixes a large number of other machines. This is a preferable solution. So at least since HP, Dell, Lenovo (also Acer?) are selling pre-loaded Linux laptops, you should be smart enough to take such a thing where the BIOS is adjusted to run on Linux or you pretty much have to reckon with trouble. Argh. No. If the BIOS is adjusted to run on Linux, it indicates that we've failed. Completely. Utterly. So being Windows compatible is nice, but sticking to specifications is more important (we are far away from and never will be Windows compatibility in WMI implementation right?). No! What's the point in sticking to specifications when there's only one implementation? Windows is the de-facto specification for ACPI, and we should follow it. Next point is that if vendors pre-load their model with a specific distribution, they need such a knob. Fixing Linux is easier than fixing firmware in almost every single case. If vendors are installing Linux without working with the distribution vendor, then that's unfortunate and they're likely to have problems. I'm not going to prioritise them above the huge number of users buying hardware from vendors who aren't as foolish. Please do not think about what happens when I upgrade to the latest kernel (which should still be no problem when they know how to use this). Think about how these vendors should fix a complex Linux bug via a BIOS hot-fix update ... They shouldn't. They should push out a software update. The only way we can achieve that is to be bug-compatible with Windows. Therefore, any way in which Linux behaviour varies from Windows behaviour is a bug. The only reason to export any indication that the kernel is Linux is because our behaviour is not identical to Windows. Linux behaviour is not identical to Windows, never will be and after vendors start pre-loading also do not need to be... Wrong. But, given that that's a bug, the solution should be to fix Linux and not to encourage vendors to put workarounds in their firmware. I see it the other way round. Encourage vendors to fix their BIOSes, instead of putting Windows compatibility workarounds into the kernel. By which you mean Cater for a small market, rather than the large one? No. That would be ridiculous. Our compatibility is sufficiently good that I'm not going to recommend users buy one of the tiny number of laptops available with a supported Linux install over buying a laptop that actually fits their needs. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Wed, Feb 20, 2008 at 03:23:40PM -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Feb 2008, Matthew Garrett wrote: Let's look at this differently. Most hardware is produced by vendors who don't care about Linux. We need to make that hardware work anyway. The only way we can achieve that is to be bug-compatible with Windows. Therefore, any way in which Linux behaviour varies from Windows behaviour is a bug. The only reason to export any indication that the kernel is Linux is because our behaviour is not identical to Windows. But, given that that's a bug, the solution should be to fix Linux and not to encourage vendors to put workarounds in their firmware. That punishes vendors which actually care about Linux. These are quite rare in the laptop and desktop market, but they do exist. It doesn't punish them. They're the ones who are going to work with us to ensure that Linux works on their hardware, and their needs are going to be prioritised over those of vendors who don't care about Linux. The other choice (encourage vendors to put workarounds in their firmware instead) *does* punish users who've ended up with laptops that aren't actively supported - like, say, pretty much anything on the market. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-acpi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Version specific vendor override possibilities needed - Revert and provide osi=linux or provide a replacement
On Thu, 2008-02-21 at 00:13 -0300, Henrique de Moraes Holschuh wrote: On Wed, 20 Feb 2008, Matthew Garrett wrote: It doesn't punish them. They're the ones who are going to work with us to ensure that Linux works on their hardware, and their needs are going And since when we have to work exactly like Windows (whatever version) does in THAT case? Also, why would one thing (proper replacement for OSI(Linux)) cause any sort of difference over the other (trying to be bug-to-bug compatible with Microsoft crap). I agree with Henrique. Since we have, in fact, more Windows cases than Linux cases and for Linux, just announce that is recommended, osi=linux. Also it is possible put Linuxs bios in a kind of white-list in kernel code ... -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
