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

[Edgar E. Iglesias]

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