All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
From: Milton Miller <miltonm-ogEGBHC/i9Y@public.gmane.org>
To: Michael Ellerman <michael-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Cc: linux-ppc <linuxppc-dev-mnsaURCQ41sdnm+yROfE0A@public.gmane.org>,
	devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
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: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-06  7:55 dtc: Add python source code output Michael Ellerman
2008-11-06  7:55 ` Michael Ellerman
2008-11-07  2:31 ` David Gibson
2008-11-10 16:11 ` Milton Miller [this message]
2008-11-10 16:11   ` Milton Miller
2008-11-10 17:00   ` Jimi Xenidis
2008-11-11 15:54     ` Milton Miller
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.