[PATCH v2 3/6] Add fdtget utility to read property values from device tree
Simon Glass
sjg at chromium.org
Sat Sep 17 02:25:10 EST 2011
Hi David,
On Fri, Sep 16, 2011 at 1:18 AM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Sun, Sep 11, 2011 at 09:34:01PM -0700, Simon Glass wrote:
>> Hi David,
>>
>> Thanks for your comments.
>
> [snip]
>> >> > B) What to do when the property just doesn't fit into that format -
>> >> > either it's length is not a multiple of the fixed integer size, or
>> >> > it's not NUL-terminated for "s". Obviously some kind of error is in
>> >> > order, but in case A2 above, do we *just* error, or print what we can
>> >> > before giving up.
>> >>
>> >> Prefer to error since any output might be confusing. But I will take a
>> >> look to make sure that is easy to do.
>> >
>> > It is trivial to check in advance for the existing types - for
>> > integers just check if the property has length a multiple of the
>> > integer size, for strings check if the last byte is '\0'. Well.. then
>> > it depends a bit on how safe you want "s" to be - do you check for
>> > reasonably printable characters first or not. How easy it is to
>> > pre-check for possible future types is not neccessarily obvious of
>> > course.
>>
>> Yes I have added a check for (length % size) == 0. For strings I don't
>> think we should be picky so long as there is a NUL terminator. If you
>> don't specify a type, the utility already tries to guess, and will
>> fall back to integer or even byte if it finds the string has ctrl
>> characters. When the user says -ts I think we need to try hard to
>> obey. I can't think of any reason to store strange characters in a
>> string property, but others might.
>
> Yes, that makes sense. One reason for funny bytes in a string that
> springs to mind would be inclusion of UTF-8 or other high-bit
> character encodings.
>
> One useful extension of what you have now might be to add a "raw
> binary" format. Not much use for humans, but could be handy for
> scripts extracting blobs from the device tree. In fact, using the
> same interpretation of existing printf() descriptors, that would
> actually be equivalent to 'c'.
Yes I was thinking about how to do that as it might be useful. I think
'c' makes perfect sense. Will add to the todo.
Regards,
Simon
>
> --
> 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
>
More information about the devicetree-discuss
mailing list