From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5aLP-0000zy-1Y for qemu-devel@nongnu.org; Tue, 21 Jan 2014 07:22:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W5aKy-0004Ti-A1 for qemu-devel@nongnu.org; Tue, 21 Jan 2014 07:22:14 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36185) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W5aKy-0004TP-0O for qemu-devel@nongnu.org; Tue, 21 Jan 2014 07:21:48 -0500 Date: Tue, 21 Jan 2014 13:44:54 +0200 From: "Michael S. Tsirkin" Message-ID: <20140121114454.GC22693@redhat.com> References: <20140120212517.GD18508@ERROL.INI.CMU.EDU> <52DE4CDC.4070501@redhat.com> <20140121110202.GA22693@redhat.com> <52DE5471.5090901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52DE5471.5090901@redhat.com> Subject: Re: [Qemu-devel] RFC: ACPI, HPET._CRS, MacOSX vs. WinXP List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: imammedo@redhat.com, "Gabriel L. Somlo" , lersek@redhat.com, qemu-devel@nongnu.org, agraf@suse.de On Tue, Jan 21, 2014 at 12:05:21PM +0100, Paolo Bonzini wrote: > Il 21/01/2014 12:02, Michael S. Tsirkin ha scritto: > > > 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. > > Yeah, that's what I would like a source for. _How_ does Microsoft tweak > its ACPI implementation based on the set of feature bits that are > _OSI-probed? > > But even that is not very important because... > > > 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. > > ... do we have reason to believe that adding _OSI("Darwin") will make > some OSPM *restrict* their features further? I don't think so. > > Besides being doubly insane to me, it contradicts the spec. The spec > says that _OSI probes can be used by the OSPM to provide *more* > features, not less. It says "OSPM can choose to expose new > functionality" based on the _OSI argument string. Ow come on. New functionality is there, OSPM sees we probe for Darwin and tries to enable some broken emulation. Since windows runs on mac hardware this won't surprise me at all. > So only Mac OS X has to be tested if we probe _OSI("Darwin"). > > Paolo If we limit this by testing _OS prefix first, then fine.