Re: [PATCH 06/17] Document the linux,network-index property.

[Segher Boessenkool <segher@kernel.crashing.org>]

>>> Segher, what is the the 'other alias' mechanism you are referring
>>> to that should be dropped?  Is it this proposed linux,network-index
>>> property?  or something else?
>>
>> Just the
>>
>> 	pic0: pic@700 {
>> 		...
>> 	}
>>
>> labeling thing -- it becomes redundant when the flat tree
>> stuff would support OF-style aliases, so it can be phased
>> out then.
>
> dtc labels are *not* an alias mechanism: they're essentially a
> compile-time rather than run-time concept

Sure.  For flat device trees, you can evaluate the OF-style
aliases at compile time, too.

> and they can reference
> properties as well as nodes

I didn't know this though.  If that's useful (I don't see how
right now), you want to keep labels I suppose.

> Putting the aliases in a separate node is far less usable for the
> things labels are useful for than putting the label directly on the
> node.  Replacing labels with the OF alias mechanism is not sensible.

Well I dunno, it's used quite often in "real" OF to create
cross-references between the nodes, and I always found it
very handy.  There's no semantic difference (except with
aliases you can refer to nodes below the alias), and no big
syntactic difference either (well with labels you spread the
"short names" all over the tree, no relation between them
is immediately obvious).

> That said, auto-generating OF-style aliases from labels for the
> benefit of run-time users might be worthwhile.

Or the other way around.  Or both!

> And using /aliases
> would work about as well as the "linux,network-index" trick.

Better, like I explained already.


Segher