qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Machine description as data


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC] Machine description as data
Date: Tue, 17 Feb 2009 08:54:55 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

David Gibson <address@hidden> writes:

> On Mon, Feb 16, 2009 at 05:39:40PM +0100, Markus Armbruster wrote:
>> David Gibson <address@hidden> writes:
>> > On Fri, Feb 13, 2009 at 12:26:28PM +0100, Markus Armbruster wrote:
> [snip]
>> > I think the idea behind using IEEE1275-like trees is that there is
>> > significant overlap between the device information that IEEE1275
>> > represents, and the device information which is configurable in qemu.
>> > Ultimately whether it buys you enough depends on how large that
>> > overlap is.
>> 
>> I think that's fair.
>> 
>> I believe we don't quite know yet whether the overlap will make it
>> worthwhile.
>
> Yeah, true enough.
>
>> One way to approach this is to assume it will until proven wrong.  You
>> start with an IEEE 1275 description of the machine, and extend or adapt
>> it as you go.  My problem with that is that we don't have such
>> descriptions for the machines that interest me.  Developing them is a
>> big step that pays no immediate benefits, but blocks the little steps
>> that do pay.  Moreover, without a *real* user of the description, I'd
>> likely develop something that looks like IEEE 1275 to me, but isn't.  If
>> it turns out that IEEE 1275 is not worth it, tough, we already paid for
>> it.
>> 
>> Another way to approach this is to admit we don't know enough and punt
>> the decision until we do.  Start with the beneficial baby steps.  Limit
>> the machine description business to what is required for the baby steps,
>> making a best effort to stay close to IEEE 1275 structurally.  If it
>> turns out that IEEE 1275 is worth it, we do whatever is left to make the
>> descriptions conform to it.
>> 
>> I'm much more comfortable with the second approach.
>
> That's reasonable.  However, once you've taken enough baby steps you
> do want to be careful that you don't end up long term with something
> that's similar enough to 1275 to be confusing, but not similar enough
> to be useful.  So at some point we do want to take a look ahead and
> see how much difference there will be between the qemu-required config
> information and the 1275 dectree.

Agreed.

I think it would help if 1275 experts reviewed the baby steps for
gratuitous deviations from 1275.

[Rest snipped, helpful comments, but I don't have anything interesting
to add...]




reply via email to

[Prev in Thread] Current Thread [Next in Thread]