allow using labels with fdtget/fdtput

[Villemoes]

It can be convenient and more readable to use &label syntax with fdtget and fdtput, rather than having to know the full path. This small series adds that support by hooking into fdt_path_offset_namelen() in the same place where we already allow the first component to be an alias. Of course this only works for blobs that have been built with -@, but it shouldn't affect existing use cases.

[This is a re-opening of #89 which I managed to implicitly close in the process of rebasing the branch to current main.]

[ukleinek]

nice
Acked-by: Uwe Kleine-König u.kleine-koenig@baylibre.com

[dgibson]

Sorry, finally looking at this after far too long.

The description of the first patch is misleading. Although, yes, this does allow use of &label for fdtput and fdtget, it does a lot more than that. It essentially adds a new path syntax including labels which will be applicable essentially anywhere using libfdt.

I'm happy enough to allow the new feature for fdtget/fdtput. I'm much more hesitant to change the path semantics for every libfdt application. Especially since IEEE1275 already includes aliases as a mechanism for shortening paths (the entire creation of __symbols__ in parallel with aliases was, IMO, a bit of a mistake).

I'd prefer to see this reworked to add this explicitly as a feature for fdtput and fdtget only. A helper function to look up symbols in libfdt would be fine (which should share most of its code with the alias lookup path), but it should be invoked explicitly, not used for all path lookups.

[Villemoes]

Well, first of all, that would be massively more complicated, as essentially all code paths ("subcommands" if you will) in the fdtget/fdtput utils would need to be taught to use a new helper.

But more than that, I really intend for this to actually work for all users of libfdt - today I might have my logic in shell scripts caling fdtget/fdtput, but if I ever change that to a Python script because that ends up being nicer, I'd expect to still be able to use the same path spec via the python bindings to libfdt.

[dgibson]

Well, first of all, that would be massively more complicated, as essentially all code paths ("subcommands" if you will) in the fdtget/fdtput utils would need to be taught to use a new helper.

But more than that, I really intend for this to actually work for all users of libfdt - today I might have my logic in shell scripts caling fdtget/fdtput, but if I ever change that to a Python script because that ends up being nicer, I'd expect to still be able to use the same path spec via the python bindings to libfdt.

Ok, that's a reasonable position, but the commit message needs to pitch it as such, not describe it purely in terms of the effect on fdtget/fdtput.

I'm continuing to think about whether generally extending the path syntax in this way is ok. One basic requirement is that it's not ambiguous with existing syntax. That would arise if it was possible to have an alias beginning with &. It looks like dtc has never allowed & in property (and therefore alias) names, at least when compiling from source (see here).

However IEEE1275 does not forbid & in alias names; section 3.2.1.3 says "An alias name is a sequence of printable characters other than “/”, “\”, “:”, “[“, “]”, and “@”.". So it's possible, if unlikely, that there are old-school IEEE1275 device trees out there with aliases beginning with &. That said, it was a deliberate decision to make dtc more restrictive in this regard.

[Villemoes]

I've updated the commit message to talk more generally about tools using libfdt.