From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwgQK-0006Gy-Jt for qemu-devel@nongnu.org; Thu, 25 Aug 2011 16:21:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QwgQJ-0007IV-Go for qemu-devel@nongnu.org; Thu, 25 Aug 2011 16:21:12 -0400 Received: from mail-fx0-f45.google.com ([209.85.161.45]:46057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QwgQJ-0007IP-AD for qemu-devel@nongnu.org; Thu, 25 Aug 2011 16:21:11 -0400 Received: by fxbb27 with SMTP id b27so2309601fxb.4 for ; Thu, 25 Aug 2011 13:21:10 -0700 (PDT) Date: Thu, 25 Aug 2011 22:20:57 +0200 From: "Edgar E. Iglesias" Message-ID: <20110825202057.GE21302@zapo> References: <1314254480-22438-1-git-send-email-peter.crosthwaite@petalogix.com> <4E564DBC.8030801@codemonkey.ws> <4E56727C.3080809@codemonkey.ws> <20110825191054.GC21302@zapo> <4E56A865.5080409@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E56A865.5080409@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Peter Crosthwaite , stefanha@linux.vnet.ibm.com, qemu-devel@nongnu.org, Grant Likely , michal.simek@petalogix.com, john.williams@petalogix.com On Thu, Aug 25, 2011 at 02:54:13PM -0500, Anthony Liguori wrote: > On 08/25/2011 02:10 PM, Edgar E. Iglesias wrote: > >On Thu, Aug 25, 2011 at 11:04:12AM -0500, Anthony Liguori wrote: > >>On 08/25/2011 10:43 AM, Peter Crosthwaite wrote: > >>>Hi Anthony, > >>> > >>>So the primary motivation for using this is in embedded systems design flows > >>>where you are already working with DTS for software boot. For > >>>microblaze-linux, xilinx-ppc and the xilinx-arm platforms which we are > >>>working with, it even more makes sense as the hardware platform design tools > >>>are capable of emitting platforms descriptions as DTS. With this framework, > >>>there is no need to write another description of your system (i.e. a config > >>>file, or a hardcoded machine model). DTSs are a standardised way of > >>>describing machines in the embedded linux arena, and are our machine > >>>description source, so in one way or another, we will continue need to > >>>create QEMU machines that match a DTB. > >> > >>Yes, but as is obvious in your series, the DTB used to create the > >>guest is not necessarily what you expose to the guest. > >> > >>So whether the config you use to create the guest is DTB or > >>something else sort of doesn't matter. It's an implementation > >>detail and you should be able to easily use any number of formats. > > > >No, the point *is* to use DTS. It's an existing format, widely used > >and compatible with other tools. > > Yes, I understand. But DTS is just a data format. What matters are > the mechanisms of going from DTS -> object model. > > If we do that right, you could use DTS, INI, XML, JSON, whatever. Yup, I see what you mean. > >The dtb is passed on by different layers of the boot and is edited for > >various reasons, for example to pass on kernel cmd lines. Nothing strange > >there. > > > >The reason for removing devices from it, is simply due to lack of manpower, > >QEMU doesnt emulate all the devices in the dtb description yet. So that > >miss-"feature" will ideally go away with time. > > > >An option is ofcourse to translate the dts to what ever bolibumpa format > >qemu is using (with all the compat/versioning issues that brings). Still, > >maybe that's something to consider. Peter? > > We shouldn't have an intermediate format. We should have monitor > commands to create the device tree and then a DTS interpreter that > reads the DTS and executes the appropriate commands. > > The problem with the current series is that it mixes up these two things. > > >>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). Cheers