Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees

[John Williams <john.williams@petalogix.com>]

[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

On Fri, Sep 2, 2011 at 12:45 PM, John Williams
<john.williams@petalogix.com>wrote:

> On Fri, Aug 26, 2011 at 7:17 AM, Anthony Liguori <anthony@codemonkey.ws>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.
>

Any thoughts on our proposal?

Thanks,

John

[-- Attachment #2: Type: text/html, Size: 3491 bytes --]