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: Anthony Liguori
Subject: Re: [Qemu-devel] Machine description as data prototype, take 3
Date: Thu, 19 Feb 2009 08:36:43 -0600
User-agent: Thunderbird 2.0.0.19 (X11/20090105)

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.

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.

Regards,

Anthony Liguori




reply via email to

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