Gleb Natapov wrote: > 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 <jan.kis...@siemens.com> >>>>>> >>>>>> 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.
Then add a service to obtain a bitmap of supported keys. If that bitmap is empty... Jan
signature.asc
Description: OpenPGP digital signature