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
next prev 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.