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: Thu, 12 Feb 2009 11:25:41 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Blue Swirl wrote:
>> On 2/11/09, Anthony Liguori <address@hidden> wrote:
>>   
>>> I think your approach is pretty sound.  A few observations:
>>>
>>>  1) obviously need to eliminate the code duplication

Obviously.

>>>  2) the new code should fit with the rest of QEMU stylistically

Expand tabs.  What else?

>>>  3) I'd prefer incremental vs. perfect so let's try to do as much
>>> refactoring that will be required before actually going the full 9 yards and
>>> implementing the config file.
>>>
>>>  4) we don't have to solve all problems all at once as long as we don't
>>> regress existing features

Exactly.

>> I'd still want to see if a FDT based solution is possible before
>> taking a homebrew version.
>>   
>
> I think I mentioned earlier that I am heavily bias toward a FDT
> solution.  What I'm suggesting though is that we can do some of the
> required cleanup (like device refactoring) before introducing any of
> the tree stuff.

I proposed to start with a (hardcoded) tree, because then a lot of tasks
become independent.  And the work to put device code behind an abstract
device interface happens in the right context from the start: driven by
tree-structured configuration.  That reduces the risk of us solving a
similar, but different problem than the one we actually have.

Of course, that sets us up for replacing the actual tree data structure.
Maybe I'm naive, but how hard could that be?  It's just a decorated
tree.  A bunch of identifiers change, and a few nodes get shuffled
around.

If you don't want to risk that, I can try to make some progress on the
abstract device interface without having a tree.




reply via email to

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