On Fri, Jul 14, 2017 at 10:21:01AM +0300, Pantelis Antoniou wrote: > Hi Frank, > > On Thu, 2017-07-13 at 14:40 -0700, Frank Rowand wrote: > > On 07/13/17 14:22, Phil Elwell wrote: > > > On 13/07/2017 21:07, Frank Rowand wrote: > > >> On 07/13/17 12:38, Phil Elwell wrote: > > >> > > [snip] > > > > hope an inability to solve the problem posed by this advanced usage won't > > > prevent a solution to a simpler problem from being accepted. > > I have waited until people started commenting on this patchset before > replying. > > I think we agree on a few things to keep the discussion moving forward. > > 1. Stacked overlays are useful and make overlays easier to use. Agreed. > 2. Changing the overlay symbols format now would be unwise. Agreed. At least, I don't think updating the symbols alone would be silly without revisiting everything in the overlay format and making something completely new. > 3. A number of extensions have been put forward/requested. > > 3.1. There should be a method to place a symbol on a node that didn't > have one originally (due to vendor supplying broken DTB or being > generated by firmware at runtime). There already is. An overlay can update *anything* in the base tree, including the /__symbols__ node. Of course you need the exact path of the node to tag in the base tree, but you were always going to need that. > 3.2. Scoping symbol visibility in case of clashes. This can the ability > to put multiple path references to a single label/symbol. i.e. > foo = "/path/bar", "/path/bar/baz"; > Resolving the ambiguity would require the caller to provide it's > 'location' on the tree. I.e. a device under /path/bar/baz would resolve > to the latter. It is a big change semantically. I think this would be a nice idea, but trying to do it as a update to the existing overlay format will be really difficult verging on impossible. Better to keep this in mind as a design goal for a new format to replace overlays. -- 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:
signature.asc
Description: PGP signature
