qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Machine description as data prototype, take 3


From: Markus Armbruster
Subject: Re: [Qemu-devel] Machine description as data prototype, take 3
Date: Thu, 19 Feb 2009 16:00:33 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Markus Armbruster wrote:
>> Third iteration of the prototype.
>>
>> What about an early merge?  If your answer to that is "yes, but", what
>> exactly do you want changed?
>>   
>
> I'm all for an early merge but I think there has to be enough of the
> architectural changes in place to allow other people to understand the
> long term direction and also contribute.
>
> I think the following are required for merge:
>
> 1) introduction of a new machine init function that returns a tree
> 2) code outside of dt.c, when -drive if=ide is specified, walks the
> tree looking for a node with an IDE decoration.  Finds the appropriate
> master/slave primary/secondary slot, and hooks up the BlockDriverState
> to the IDE device.
> 3) reading the machine description from a file
>
> Basically, enough of the architecture that it's clear that we just
> need to do #2 for all of the remaining devices.  I don't think your
> that far from this today.

Okay, I'll attack (1) and (2) next, and then we can talk again.

>> New:
>>
>> * Rebased to git-svn-id: svn://svn.savannah.nongnu.org/qemu/address@hidden 
>> c046a42c-6fe2-441c-8c8c-71466251a162
>>
>> * Code duplication cleaned up.  I chose minimizing the impact on pc.c
>>   over nice, clean interfaces.  Happy to rework it if that was the wrong
>>   choice.  I think there are a few opportunities for cleanup that would
>>   improve pc.c even without taking dt.c into consideration.  I can work
>>   on patches if you like.
>>
>> * The "device required" edges moved from struct tree to struct dt_device
>>   to make the configuration tree more similar to FDTs structurally.
>>
>> * A bunch of pointless typedefs to hopefully blend in better
>>   stylistically.  Tabs expanded.  If style issues remain, please point
>>   them out to me!
>>   
>
> I'll respond in a separate note but the style is still off.

Appreciated.




reply via email to

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