On Nov 10, 2008, at 10:11 AM, Milton Miller wrote:
On 2008-11-07 at 02:31:40, David Gibson wrote:
On Thu, Nov 06, 2008 at 06:55:44PM +1100, Michael Ellerman wrote:
This commit adds an output format, which produces python
code. When run, the python produces a data structure that
can then be inspected in order to do various things.
...
I'm not sure if this is generally useful (or sane) but it was for
me so
I thought I'd post it.
Hrm, well the idea of langauge source output seems reasonable. But
the actual data structure emitted, and the method of construction in
Python both seem a bit odd to me.
I have a dts that I want to use to configure a simulator, and this
seemed like the nicest way to get there. dtc spits out the
pythonised
device tree, and then I have a 10 line python script that does the
configuring.
[snip]
These branches also result in the value having different Python types
depending on the context. That's not necessarily a bad thing, but
since which Python type is chosen depends on a heuristic only, it
certainly needs some care. You certainly need to be certain that you
can always deduce the exact, byte-for-byte correct version of the
property value from whatever you put into the Python data structure.
+
+out:
+ fprintf(f, " n.properties.append(p)\n");
So, emitting Python procedural code to build up the data structure,
rather than a great big Python literal that the Python parser will
just turn into the right thing seems a bit of a roundabout way of
doing this.
I would think so too. I haven't looked at the output, only at
Davids comments. If the data structure is ambiguous, then I do
think more thought is needed.
There is value in the DTC (optionally) emitting a python library and
then having the DTC result use it.
It would allow for python to easily, at runtime, be able to modify the
contents and not have to inline-edit, emit, compile a DTS.
BTW: it would also be nice if the python library to dump the dts (or
even dtb)
Have you considered just parsing the flat tree binary? Either
creating a python binding to libfdt or even just parsing the dtb
directly?
I have written perl code to parse a dtb and query it for nodes and
properties, it wasn't too bad. I need to look at a bug report by
another user and comment it, then I should seek the okays post it.
It is currently read-only and iterative callback based (like the
kernels early-scan-flat-tree stuff), but I have planned creating a
tree for querying, editing, and re-flattening. Perl strings are
counted length binary blobs, so property contents are interpreted
with pack and unpack. The library has been used to search a dtb to
build a list of cpu instances and memory blocks, and it has been
used to query the properties of a known node in the tree.
milton
_______________________________________________
devicetree-discuss mailing list
[EMAIL PROTECTED]
https://ozlabs.org/mailman/listinfo/devicetree-discuss
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
