David Gibson wrote:
On Thu, Mar 01, 2007 at 11:08:38PM -0500, Jerry Van Baren wrote:
[snip]
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. :-/
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]
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?
Where I am right now is I created a new function fdt_fullpath_offset:
int fdt_fullpath_offset(const void *fdt, const char *path, char **prop);
which will return the _node_ /a/b in the gaak illustration above. It looks up nodes until it either runs out of path to look up or there is an error. On a lookup error, it tries again with the last part of the path used as a property name. As a result, if you pass in /a it will return the node "a", if you pass in /a/b it will return the _node_ "b". This is unchanged behavior compared to fdt_path_offset(). (Getting property "b" is unchanged: you would have to look up node /a with either fdt_fullpath_offset(... "/a" ...) or fdt_path_offset(... "/a" ...) and then use that offset with fdt_property() to get the property "b".)
I really don't like this idea much. I don't think it's sufficiently useful to justify the increased implementation complexity and semantic confusion.
But that is the human notation, or am I making incorrect assumptions? I'm new to OF and fdt notation.
[snip]
FWIIW, this is what I have running in u-boot...
---------------------------------------------------------------- gaak.dts ---------------------------------------------------------------- /* * Ugly ugly ugly tree for testing. */ / { model = "gaak"; compatible = "notlikely"; #address-cells = <1>; #size-cells = <1>; linux,phandle = <100>;
ugly = "first level property ugly"; ugly { ugly { ugly = "third level property ugly"; }; /**** dtc doesn't allow having a property after a node ugly = "second level property ugly"; ****/ }; /**** dtc doesn't allow an anonymous node other than the root one? { ugly = "ugly property in anonymous node"; }; ****/ }; ---------------------------------------------------------------- u-boot "fdt" output ---------------------------------------------------------------- => fdt print / / { model="gaak" compatible="notlikely" #address-cells=<00000001> #size-cells=<00000001> linux,phandle=<00000100> ugly="first level property ugly" ugly { ugly { ugly="third level property ugly" } } } => fdt print /ugly ugly { ugly { ugly="third level property ugly" } } => fdt get /ugly /ugly="first level property ugly" ----------------------------------------------------------------
Oops, I forgot to print the semicolons on the tree dump. Something to fix tomorrow^W later today.
Best regards, gvb