On Fri, Sep 2, 2011 at 12:45 PM, John Williams <john.willi...@petalogix.com>wrote:
> On Fri, Aug 26, 2011 at 7:17 AM, Anthony Liguori <anth...@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
