Gleb Natapov wrote: > On Wed, Jun 16, 2010 at 09:57:35AM +0200, Jan Kiszka wrote: >> 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... >> > Bitmap will be 2k long. We can add read capability to control port. To > check if key is present you select it (write its value to control port) > and then read control port back. If values is non-zero the key is valid. > But how to detect qemu that does not support that?
Isn't there some key that was always there and will always be? Jan
signature.asc
Description: OpenPGP digital signature
