From: David Gibson <david@gibson.dropbear.id.au>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] RFA & Update: Using libfdt in u-boot for fdt command
Date: Sat, 3 Mar 2007 09:31:40 +1100 [thread overview]
Message-ID: <20070302223140.GA11166@localhost.localdomain> (raw)
In-Reply-To: <45E86E77.3020305@smiths-aerospace.com>
On Fri, Mar 02, 2007 at 01:35:35PM -0500, Jerry Van Baren wrote:
> Jerry Van Baren wrote:
> > David Gibson wrote:
[snip]
> OK, here is a reference on the OF device tree browsing commands:
> <http://www.firmworks.com/QuickRef.html#Device%20Tree%20Browsing>
>
> Where I'm coming from is that I've written the "fdt print" command to
> put out the same text (possibly with data formatting differences) as
> went into the dtc to create the blob. This is very useful and intuitive
> to me.
>
> The OF device tree browsing is modeled after filesys directory and file
> browsing (sorta).
> ".properties" ~ "ls" but only shows files (properties ~ files)
> "dev" == "cd"
> "ls" == "ls -d *" (only shows subdirectories)
> "pwd" == "pwd"
> "dend" - has no equiv
> "show-devs" - has no equiv, sounds like it may be my "print" command
> "words" - has no equiv, does not apply (dir *.exe in DOS :-)
> "sift-devs ccc" == find . -name "*ccc*"
>
> Looks a lot more complex with no clear benefit for u-boot.
Sorry, I was unclear. I wasn't trying to suggest you use the OF
client interface model for device tree commands in general. Just that
you don't treat properties as having paths.
> I have not found any character that could clearly and cleanly be used to
> separate the node path from the property name.
> * Comma ',' - used to separate a device name from an argument - one
> could argue that the property name is an argument to the path.
> "/foo/bar,baz" is the property baz under the node "/foo/bar".
> * Space ' ' - "/foo/bar/baz" is a node path, "/foo/bar baz" is the
> property baz under the node "/foo/bar". Spaces complicate parsing.
Space only complicates parsing if you insist of thinking of these
things as paths-to-properties, which is not really a good idea in the
first place. Just think of the node-path and the property name as
separate parameters to your commands.
So, getprop takes 2 parameters (node, property), setprop takes 3
(node, property, value). print, or whatever you end up calling it
takes either 1 or 2 (node, plus optional property name)
> Any strong opinions? At this point I don't see any reason to change
> from my current technique and proposed command set for u-boot.
--
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
next prev parent reply other threads:[~2007-03-02 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-01 14:01 [U-Boot-Users] 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 ` 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
2007-03-02 5:36 ` David Gibson
2007-03-02 12:31 ` Jerry Van Baren
2007-03-02 18:35 ` Jerry Van Baren
2007-03-02 22:31 ` David Gibson [this message]
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=20070302223140.GA11166@localhost.localdomain \
--to=david@gibson.dropbear.id.au \
--cc=u-boot@lists.denx.de \
/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