Re: [PATCH v2 3/6] Add fdtget utility to read property values from device tree

[Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>]

Hi David,

On Wed, Sep 7, 2011 at 10:25 PM, David Gibson
<david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> wrote:
> On Wed, Sep 07, 2011 at 12:54:17PM -0700, Simon Glass wrote:
>> This simply utility makes it easy for scripts to read values from the device
>> tree. It is written in C and uses the same libfdt as the rest of the dtc
>> package.
>>
>> What is it for:
>> - Reading fdt values from scripts
>> - Extracting fdt information within build systems
>> - Looking at particular values without having to dump the entire tree
>>
>> To use it, specify the fdt binary file on command line followed by a list of
>> node, property pairs. The utility then looks up each node, finds the property
>> and displays the value.
>>
>> Each value is printed on a new line.
>>
>> fdtget tries to guess the type of each property based on its contents. This
>> is not always reliable, so you can use the -t option to force fdtget to decode
>> the value as a string, or byte, etc.
>>
>> To read from stdin, use - as the file.
>>
>> Usage:
>>       fdtget <options> <dt file> [<node> <property>]...
>> Options:
>>       -t [<type>][<format>]   Type of data
>>       -h              Print this help
>>
>>       <type>          One character (s=string, i=int, u=unsigned, b=byte)
>>       <format>        Optional format character (x=hex)
>
> It is not terribly clear how these are combined.

A type character, then an optional format character. In fact the type
character is also optional at present since integer is assumed.

Please can you suggest a suitable help message to convey this?

>
> Is there any way to make these more closely resemble printf() style
> format specifiers?

The first patch series allowed printf specifiers but could segfault if
the user specified %s for something that was in fact not a string. I
have moved away from that as you suggested at the time. I am not keen
to re-implement printf(), or manually decode a partial subset of
printf strings, to avoid that problem. So something simple like this
is what I have come up with.

We need to encode the data size in there also - byte or integer - so
it is not quite the same as what printf is trying to do. While
printf() has %c I don't think it is a good idea to use that, since we
are printing a byte as a number, not an ASCII character.

But it is fairly close to printf, in that you can use:

-ts
-tx
-ti
-tu
-tix
-tbx

We could combine -tbx into a single letter somehow but I'm not sure I
like that idea.

I don't see any point in requiring a % since then users would expect
to be able to provide an arbitrary printf() string (see first patch
set).

So, suggestions please.

Regards,
Simon

>
>>
>> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
>> ---
>> Changes in v2:
>> - Separate arguments for node and property
>> - Merge two related commits into this one
>> - Use structure for storing display options
>> - Remove use of getopt_long()
>>
>>  .gitignore      |    1 +
>>  Makefile        |    4 +
>>  Makefile.fdtget |   12 +++
>>  fdtget.c        |  200 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  4 files changed, 217 insertions(+), 0 deletions(-)
>>  create mode 100644 Makefile.fdtget
>>  create mode 100644 fdtget.c
>>
[snip]
>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                | _way_ _around_!
> http://www.ozlabs.org/~dgibson
>