On Fri, Aug 01, 2008 at 07:36:57PM -0300, Henrique de Moraes Holschuh wrote:
quoted text
> On Fri, 01 Aug 2008, Len Brown wrote:
> > It is better to expose ourselves to the known tested Windows functionality
> > -- even if it seems arbitrary, at least it is tested.  The !Windows case
> > results in running _completely_ untested BIOS code.
> 
> Actually, we should masquerade properly as the latest Windows version
> available for that machine, then.  AFAIK, Windows does not set ALL the OSI
> strings, just one.  We ARE running untested code in some BIOSes because of
> it.

The BIOSes I've tested check _OSI in order of Windows release, which is 
consistent with Windows returning OSI strings for all previous versions. 
Do you have any examples that suggest this isn't the case?

quoted text
> Maybe it would be better if every ACPICA-using OS defined a
> _OSI(NotWindows), plus the relevant Windows OSI string they want to support,
> and Intel would send word that this string is to be used ONLY to disable all
> Windows bug workarounds, not to activate or deactivate any specific
> functionality?

Not all BIOSes would support this, so we'd need to support the Windows 
workarounds anyway. At that point, there's no real benefit in having 
multiple codepaths.

-- 
Matthew Garrett | mjg59@srcf.ucam.org
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/