From: Jerry Van Baren <gerald.vanbaren@comcast.net>
To: David Gibson <david@gibson.dropbear.id.au>,
u-boot-users@lists.sourceforge.net, linuxppc-dev@ozlabs.org
Subject: Re: RFA & Update: Using libfdt in u-boot for fdt command
Date: Fri, 02 Mar 2007 00:25:17 -0500 [thread overview]
Message-ID: <45E7B53D.6020603@comcast.net> (raw)
In-Reply-To: <20070302044815.GI1687@localhost.localdomain>
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
next prev parent reply other threads:[~2007-03-02 5:25 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 14:01 RFA & Update: Using libfdt in u-boot for fdt command Jerry Van Baren
2007-03-01 23:49 ` Mark A. Greer
2007-03-02 1:17 ` [U-Boot-Users] " Jerry Van Baren
2007-03-02 20:53 ` Mark A. Greer
2007-03-02 1:55 ` David Gibson
2007-03-02 4:08 ` Jerry Van Baren
2007-03-02 4:48 ` David Gibson
2007-03-02 5:25 ` Jerry Van Baren [this message]
2007-03-02 5:36 ` David Gibson
2007-03-02 12:31 ` Jerry Van Baren
2007-03-02 18:35 ` [U-Boot-Users] " Jerry Van Baren
2007-03-02 22:31 ` David Gibson
2007-03-02 18:38 ` Jerry Van Baren
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=45E7B53D.6020603@comcast.net \
--to=gerald.vanbaren@comcast.net \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.org \
--cc=u-boot-users@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).