From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=57112 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOPz5-0001HZ-Ab for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:50:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOPz4-0004T8-8X for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:50:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:18320) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOPz3-0004Sx-Vu for qemu-devel@nongnu.org; Tue, 15 Jun 2010 02:50:54 -0400 Date: Tue, 15 Jun 2010 09:50:48 +0300 From: Gleb Natapov Message-ID: <20100615065047.GL21797@redhat.com> References: <20100614083053.GC21797@redhat.com> <20100614135425.GA18002@morn.localdomain> <20100614140959.GI21797@redhat.com> <4C1641EF.9070001@redhat.com> <20100614182521.GA22454@morn.localdomain> <4C16852F.9070904@codemonkey.ws> <4C1705FB.2040605@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C1705FB.2040605@redhat.com> Subject: [Qemu-devel] Re: [SeaBIOS] [PATCHv2] load hpet info for HPET ACPI table from qemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: seabios@seabios.org, qemu-devel@nongnu.org On Tue, Jun 15, 2010 at 07:47:55AM +0300, Avi Kivity wrote: > On 06/14/2010 10:38 PM, Anthony Liguori wrote: > > > >I think we can be pretty flexible as long as we're careful about > >releases. For instance, I've applied Gleb's current patch but > >won't update SeaBIOS until the interface is worked out. If we > >decide to implement a new interface, there's no harm since we've > >never had a qemu build that had a combination of SeaBIOS and > >fw_cfg that didn't work. > > Or we can choose a new interface number if the interface changes. > > One of Kevin's points was that the ACPI tables are a documented > interface. AFAIR, the firmware configuration interface isn't. We > need to start documenting it (and reject patches without > accompanying documentation). > ACPI tables are, indeed, documented interface (it doesn't make it good interface though :)), but it is interface between firmware and OS, so it may (and it does) have things like "if firmware support that, then this bit should be set". Using it as interface to describe HW to firmware is just plain abuse. -- Gleb.