On Tue, Jan 21, 2014 at 11:33:00AM +0100, Paolo Bonzini wrote: > 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.
Exactly, I read it that way too. > 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. Insane, yes. This is however what windows does and this is what microsoft document explicitly says. > 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 We restrict ourselves to a very small subset of the spec that seems to work well everywhere, and so far OSPMs seem to assume that's what no _OSI means. -- MST