[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions
From: |
Kevin O'Connor |
Subject: |
[Qemu-devel] Re: [PATCH][SEABIOS] Move qemu config port access functions into separate file. |
Date: |
Fri, 2 Oct 2009 15:31:14 -0400 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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