On Nov 10, 2008, at 10:11 AM, Milton Miller wrote:

On 2008-11-07 at 02:31:40, David Gibson wrote:

quoted

On Thu, Nov 06, 2008 at 06:55:44PM +1100, Michael Ellerman wrote:

quoted

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.

...

quoted

quoted

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.

quoted

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]

quoted

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.

quoted

+
+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
devicetree-discuss@ozlabs.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss