Il 20/01/2014 22:25, Gabriel L. Somlo ha scritto: > > "Implementation Note > Place the routine that identifies the operating system in an _INI method > under the \_SB scope so that _OSI can run as early as possible. This > placement is important because the operating system makes features > available based on the string argument to the _OSI method." > > It all depends on what the document's author meant by "the operating > system" which "makes features available". Because somewhere earlier in > the document they say: > > "Recent versions of the ACPI spec have extended the use cases of > the _OSI method beyond host operating system version identification. > However, Windows supports _OSI only for the use of identifying the host > version of Windows that is running on the system."
I read that as referring to things like _OSI("3.0 Thermal Model"). It means (the way I read it) that Windows will not publish that kind of _OSI string. I think it is safe to assume that no OSPM will do those crazy things with OS-defined _OSI strings (it's quite plausible that they do it with feature _OSI strings). First, because IMHO it is completely insane. Second, because the current DSDT would also be theoretically broken with an OSPM that does strange things with _OSI. We never call _OSI, so the OSPM could presume that it should "disable all features". Paolo