Re: RFA & Update: Using libfdt in u-boot for fdt command

On Fri, Mar 02, 2007 at 12:25:17AM -0500, Jerry Van Baren wrote:

David Gibson wrote:

quoted

On Thu, Mar 01, 2007 at 11:08:38PM -0500, Jerry Van Baren wrote:

[snip]

quoted

quoted

to give me a pointer to the node name for node tags and property name 
for property tags.  Now that I have it working, it would be trivial to 
change the calls to _fdt_next_tag() to instead call fdt_next_tag() 
passing NULL for the new fourth parameter **namep. ;-)

The reason I need it, I'm printing an unknown tree by stepping through 
the tree discovering the node and property names.  I need to have 
fdt_next_tag() return the *name* of the node/property as well as the tag 
so that I can print and indent for nodes or look up the property value 
and print the name=value combination.

Hrm.  And it returns NULL for tags without a name?

I was unable to generate a tag without a name using dtc (other than the 
root node).  It should/would return null, which would be a problem. :-/

I was thinking more of tag types which don't have a name, to wit,
FDT_END_NODE and FDT_NOP.

quoted

That might be a useful extension for the next_tag function.  The one
thing I'm concerned about is who's responsible for verifying the name
pointer.  I'm trying to keep libfdt robust enough that evern if
presented with a badly corrupt blob it will fail relatively
gracefully.  Ideally, no matter what it's presented with, it will
always return at worst FDT_ERR_BADSTRUCTURE rather than crashing and
will under no circumstances access memory outside the given blob
size.

[snip]

quoted

quoted

Oh gaak!  What I hear you saying... if you have node a with subnode b 
and property b, subnode b has a property c:
/a     => node
/a/b   => node
/a/b   => property (inside node a)
/a/b/c => property (inside node b)

Well, yes.  Except that in OF and derived terminology, properties are
*never* referred to by path in this way.  It's always:
"property 'fred' of node /foo/bar/baz"

I'm coming from a human interface syntax point of view and assumed that 
the human interface is paths like linux where the last item is a 
directory or file with the computer guessing what you really meant 
(which _isn't_ ambiguous in file/dir paths).  Is there a better syntax 
for distinguishing between node paths and properties?

You assumed incorrectly.  Well, unless you count /proc/device-tree as
a human interface to the device tree, which isn't entirely
unreasonable.  OF certainly doesn't use that approach, it uses state
instead, first "dev /foo/bar/baz" then ".properties" or "setprop ....".

-- 
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