|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] [RFC PATCH V1 00/14] Dynamic machine model creation from device trees |
Date: | Thu, 25 Aug 2011 14:54:13 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |