Supporting aliases in PATHREFs

Supporting aliases in PATHREFs

[Kumar Gala]

We currently have support for referring to a path via:

&{/foo/bar}
{
  …
};


Was looking at supporting aliases in that as well, so you could have:

aliases {
   aname = &{/foo/bar};
};

&{aname}
{
…
};

As I look at making the changes to support this, had a few questions:
1. So we use DT_PATH_REF in the lexer for this, or introduce something like DT_ALIAS_REF?
2. On the yacc side, looks like there is get_node_by_ref() and add_orphan_node() would need changing to distinguish a PATH, ALIAS, and LABEL reference as right now they utilize the ref starting with “/“ to distinguish between PATH & LABEL references.  Would passing a 3rd parameter that is some ENUM type be the way to go here?
3. Are there any other places I should look to fix things so aliases can be used similar to a path?

I’m not super familiar with lex/yacc so looking for guidance.

thanks

- k

Re: Supporting aliases in PATHREFs

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

On Wed, May 20, 2020 at 11:04:54AM -0500, Kumar Gala wrote:
> We currently have support for referring to a path via:
> 
> &{/foo/bar}
> {
>   …
> };
> 
> 
> Was looking at supporting aliases in that as well, so you could have:
> 
> aliases {
>    aname = &{/foo/bar};
> };
> 
> &{aname}
> {
> …
> };
> 
> As I look at making the changes to support this, had a few questions:
> 1. So we use DT_PATH_REF in the lexer for this, or introduce
> something like DT_ALIAS_REF?

I think generalizing DT_PATH_REF would be a better idea.  The {}
present in path and alias refs but not not label refs should be enough
to distinguish it there.

> 2. On the yacc side, looks like there is get_node_by_ref() and
> add_orphan_node() would need changing to distinguish a PATH, ALIAS,
> and LABEL reference as right now they utilize the ref starting with
> “/“ to distinguish between PATH & LABEL references.  Would passing a
> 3rd parameter that is some ENUM type be the way to go here?

I'd treat alias references as an extension of path references even
here.  In OF you can traditionally use an alias as the first element
of a path, instead of / - and, for example, fdt_path_offset() will
resolve paths of that format.  So that would let you use a reference
like &{aname/baz} as a bonus.

I'm not immediately sure whether it would be better to have an enum
parameter, or to just have separate functions to resolve label and
path references.  Depends how much common code there is.

> 3. Are there any other places I should look to fix things so aliases
> can be used similar to a path?

Probably...


My only real concern with this proposal is that it makes a pretty
subtle distinction between &aname and &{aname} which might make
reading dts files a bit hardware for humans.

How much does allowing alias references buy over using a label, like:

aname: &{/foo/bar} {
	...
};

aliases {
	aname = &aname;
}

&aname {
	...
};

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]