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
