From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Mime-Version: 1.0 (Apple Message framework v624) In-Reply-To: <1225958144.25986.9.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <25b7edabcd3d50a8d399ac5208a7ecb6@bga.com> From: Milton Miller Subject: Re: dtc: Add python source code output Date: Mon, 10 Nov 2008 10:11:53 -0600 To: Michael Ellerman Cc: linux-ppc , devicetree-discuss@ozlabs.org, David Gibson List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. 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