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
