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

[Anthony Liguori]

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.

> 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.

Another way to put it, limit the logic strictly to invoking qdev 
operations derived from the DTS.  You'll see that there are things you 
can't do but the point is that we need to fix qdev to make it possible 
to do those things.

Regards,

Anthony Liguori

> Cheers