From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=32932 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOnQl-00056u-Gz for qemu-devel@nongnu.org; Wed, 16 Jun 2010 03:53:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOnQk-0006oY-6x for qemu-devel@nongnu.org; Wed, 16 Jun 2010 03:53:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49429) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOnQk-0006oR-03 for qemu-devel@nongnu.org; Wed, 16 Jun 2010 03:53:02 -0400 Date: Wed, 16 Jun 2010 10:52:59 +0300 From: Gleb Natapov Message-ID: <20100616075259.GA21797@redhat.com> References: <4C18015C.1070306@web.de> <20100616044047.GF13238@redhat.com> <4C187725.2000902@web.de> <20100616073318.GZ21797@redhat.com> <4C188272.9010201@web.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C188272.9010201@web.de> Subject: [Qemu-devel] Re: [PATCH] hpet: Clean up initial hpet counter List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel On Wed, Jun 16, 2010 at 09:51:14AM +0200, Jan Kiszka wrote: > Gleb Natapov wrote: > > On Wed, Jun 16, 2010 at 09:03:01AM +0200, Jan Kiszka wrote: > >> Gleb Natapov wrote: > >>> On Wed, Jun 16, 2010 at 12:40:28AM +0200, Jan Kiszka wrote: > >>>> From: Jan Kiszka > >>>> > >>>> There is no need starting with the special value for hpet_cfg.count. > >>>> Either Seabios is aware of the new firmware interface and properly > >>>> interprets the counter or it simply ignores it anyway. > >>>> > >>> I want seabios to be able to distinguish between old qemu and new one. > >> I see now. But isn't it a good chance to introduce a proper generic > >> interface for exploring supported fw-cfg keys? > >> > > Having such interface would be nice. Pity we haven't introduced it from > > the start. If we do it now seabios will have to find out somehow that > > qemu support such interface. Chicken and egg ;) > > That is easy: Add a key the describes the highest supported key value > (looks like this is monotonously increasing). Older qemu versions will > return 0. > That will not support holes in key space, and our key space is already sparse. -- Gleb.