[U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

[David Gibson <david@gibson.dropbear.id.au>]

On Sat, Aug 02, 2008 at 08:51:54PM -0400, Jerry Van Baren wrote:
> Kumar Gala wrote:
>>
>> On Jul 9, 2008, at 12:02 PM, Jerry Van Baren wrote:
>>
>>>
>>> Thinking out loud... we could define the syntax that a leading "*"  
>>> indicates the first part of the path is a dereference of /aliases.
>>>
>>> Assuming
>>>  /aliases/soc = /soc8360 at e000000
>>>  /aliases/ethernet0 = /soc8360 at e0000000/.../enet0
>>> then
>>>  print *soc/enet0
>>> and
>>>  print *ethernet0
>>> would both work and print the right thing.  You *would* have to know  
>>> that the first element of the path is an /aliases dereference.  Your  
>>> original patch did not require that piece of knowledge (but silently  
>>> and automagically, which makes me nervous).
>>
>> did we come to resolution on this?  I'd like to see this in 1.3.5.
>>
>> - k
>
> Hi Kumar,
>
> I think we have basic resolution - I would like to see it in 1.3.5 too.  
> I haven't pushed on this, waiting for 1.3.5 window to open (or some free 
> time, whichever comes last).
>
> I've CC:ed David Gibson in case he has some advice - the concept is to  
> indicate a dereference of /aliases nodes so that us lazy engineers don't  
> have to cut'n'paste the whole long path from the alias.  Kumar  
> originally proposed to do it automagically and I countered proposing  
> using "*" to indicate the next path name should be looked up in /aliases  
> and the result used instead (i.e. dereferenced).  Discussion thread:
> <http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/43575/focus=44941>

No, I really don't think using this "dereference" character is a good
idea.  If you're going to expand aliases, you should do it as real OF
does - see section 4.3 of IEEE1275.  Essentially it's the *lack* of a
leading '/' character that triggers alias expansion.  So you could use
e.g.
	/soc8360 at e0000000/ethernet at e0000400
or
	soc/ethernet at e0000400
or
	ethernet0

> Looking at the ieee1275 doc
> <http://playground.sun.com/pub/1275/coredoc/1275-1994/1275.ps.gz>
> it looks like "*" will work for a dereference delimiter as it is not  
> listed as one of the permitted punctuation characters in a node name.  
> Quoting 3.2.1.1 Node names:
> ----------------------------------------------------------------------
> The driver name field is a sequence of between one and 31 letters,  
> digits, and punctuation characters from the set ", . _ + - ". Uppercase  
> and lowercase characters are distinct.
> ----------------------------------------------------------------------
>
> We do have a problem with property names, where "*" _is_ a legal name  
> component.  Quoting 3.2.2.1.1 Property names:
> ----------------------------------------------------------------------
> The property name is a human-readable text string consisting of one to  
> thirty-one printable characters. Property names shall not contain  
> uppercase characters or the characters "/", "\", ":", "[", "]" and "@".
> ----------------------------------------------------------------------
> Note that "*" is not proscribed, making it a legal character in a  
> property name.

I've observed a '*' in the device tree in the wild - some Apple tree,
unfortunately I can't find it right at the moment.  So I can't check
if the '*' was in a node node, making it IEEE1275 illegal, or in a
property name.  I remember thinking it was illegal at the time, but I
thought '*' was invalid in property names too, which seems to have
been a misinterpretation.

> Having noted that, I'm willing to take the risk and use "*" for the  
> "alias dereference" separator.
>
> Looking back at the original patch, Kumar's original patch only did the  
> /aliases dereference for the "fdt print" command.  I'm thinking more  
> general purpose: being able to dereference /aliases in all "fdt"  
> commands.  This seems helpful for the "fdt set" command, for instance.  
> Whether this is reasonable to implement remains to be seen...

If you're interepreting them in one place, you should probably
interpret them everywhwere and have a single "resolve pathname"
function.  In fact, I should quite possibly put such a function into
libfdt.

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