On Fri, Aug 26, 2011 at 7:17 AM, Anthony Liguori
<address@hidden> wrote:
On 08/25/2011 03:20 PM, Edgar E. Iglesias wrote:
On Thu, Aug 25, 2011 at 02:54:13PM -0500, Anthony Liguori wrote:
On 08/25/2011 02:10 PM, Edgar E. Iglesias wrote:
This is the goal of QOM except it does this by fixing the problems
in qdev instead of adding another layer on top of things.
Then maybe the FDT machinery could be respinned to work on top of your QOM
objects?
Or are FDT's a complete no go? So external conversion is the only option?
No, DTS is fine but not as proposed. You shouldn't mix the logic of
creating the nodes in the tree with the format of how you're
describing what nodes to be there.
Thanks. Would you mind spending a few lines on how far you've gotten with
QOM and if there is, where to find more info about it (sorry, I havent been
following it at all).
Stay tuned. I'm going to spend the day tomorrow getting the next series ready and writing some stuff on the wiki.
It seems that the main issue raised is not about the quality of the work being contributed, nor the overall intent, but rather an _expression_ that it might be better done building on a layer which itself is still a work in progress, I'd like to propose a compromise.
This is a long term investment for us, we have two working architectures, numerous users, and immediate plans to add support for a 3rd architecture. We are committed to doing it the right way, and letting people other than our immediate customers benefit from our work. However, there is also a significant cost to us maintaining this out-of-tree - something breaks every time we pull from mainline.
So, may I ask that the code be reviewed on its technical merit as it stands today, and if that is suitable then it be merged, with a commitment from us that when there is suitable plumbing in place our work will be refactored around that? Indeed, the process of us doing so will probably provide useful feedback in the design of these underlying layers.