linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Milton Miller <miltonm@bga.com>
To: Michael Ellerman <michael@ellerman.id.au>
Cc: linux-ppc <linuxppc-dev@ozlabs.org>,
	devicetree-discuss@ozlabs.org,
	David Gibson <david@gibson.dropbear.id.au>
Subject: Re: dtc: Add python source code output
Date: Mon, 10 Nov 2008 10:11:53 -0600	[thread overview]
Message-ID: <25b7edabcd3d50a8d399ac5208a7ecb6@bga.com> (raw)
In-Reply-To: <1225958144.25986.9.camel@localhost>

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

  parent reply	other threads:[~2008-11-10 16:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06  7:55 dtc: Add python source code output Michael Ellerman
2008-11-07  2:31 ` David Gibson
2008-11-10 16:11 ` Milton Miller [this message]
2008-11-10 17:00   ` Jimi Xenidis
2008-11-11 15:54     ` Milton Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=25b7edabcd3d50a8d399ac5208a7ecb6@bga.com \
    --to=miltonm@bga.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=devicetree-discuss@ozlabs.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=michael@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).