[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file.

[Kevin O'Connor]

Hi Gleb,

On Fri, Oct 02, 2009 at 08:10:10PM +0200, Gleb Natapov wrote:
> How many config options do you expect?

I expect about a dozen.

> > > That is why qemu chose to provide name/value interface.
> > I'm a bit confused here.  As near as I can tell, qemu has an
> > int_id->value mapping.  What I'd like to see is a string_name->value
> What is the difference? Why do you care if it is int->value or
> string->value?

We seem to have not been effectively communicating.  The original
patch you sent has a simple and sane abstraction around the existing
qemu int->value configuration system.  I liked it (with the few
comments I sent earlier), and think it should be committed.

I was raising the possibility/hope that qemu could be extended with a
string->value system for passing parameters.  Such a system would
simplify SeaBIOS a little.  I'm not familiar with qemu development,
and if this was a "theoretical" distraction, then I'm sorry for
raising it.

To answer your question, the reason I prefer string->value is that it
allows me to use the same namespace for both coreboot and qemu.
Configuration enhancements made for one environment can automatically
be utilized by the other.

>I can easily map string to int in seabios qemu config
> functions so for the rest of seabios it will look just like string->value.
> I don't see the point of doing this though.

Agreed - that would not be productive.

> > If qemu is willing to add this to the backend (ie, the emulator passes
> > the info to the bios as string_name->value), then great.  The actual
> Qemu is not (or shouldn't be) developed in a lockstep with a bios. Bios
> should be flexible enough to support older or newer qemus. Seabios
> should treat qemu just like any other HW mobo. Even if we add something to
> qemu now we want to support older qemus too.

Also agreed.  As an example of this, qemu is currently passing some
config parameters via nvram - in a "theoretical" way, I'd like to see
these normalized to name->value - but even if that did happen SeaBIOS
would need to continue to support the old method.

> > specifics of how it is done isn't of great concern to me.  If not,
> > then lets go forward with the basic int_id support.  The internal API
> > for coreboot can be figured out when the coreboot config support is
> > added.
> > 
> You mean like in my first patch? I can resend it with all other points
> addressed.

Yes. Thanks.
-Kevin