On Tue, Jan 16, 2018 at 09:32:41AM -0600, Kyle Evans wrote: > On Tue, Jan 16, 2018 at 7:30 AM, David Gibson > <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Jan 12, 2018 at 09:57:26AM -0600, Kyle Evans wrote: > >> On Thu, Jan 11, 2018 at 11:33 PM, David Gibson > >> <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > >> > On Fri, Jan 05, 2018 at 12:40:13PM -0800, Frank Rowand wrote: > >> >> On 01/04/18 21:47, Kyle Evans wrote: > >> >> > On Thu, Jan 4, 2018 at 11:02 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >> >> >> On 01/04/18 19:50, Kyle Evans wrote: > >> >> >>> On Thu, Jan 4, 2018 at 9:14 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >> >> >>>> On 01/04/18 18:39, Kyle Evans wrote: > >> >> >>>>> On Thu, Jan 4, 2018 at 7:55 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >> >> >>>>>> On 01/04/18 13:47, Kyle Evans wrote: > >> >> >>>>>>> On Thu, Jan 4, 2018 at 3:34 PM, Kyle Evans <kevans@xxxxxxxxxxx> wrote: > >> >> >>>>>>>> On Thu, Jan 4, 2018 at 2:41 PM, Kyle Evans <kevans@xxxxxxxxxxx> wrote: > >> >> >>>>>>>>> On Thu, Jan 4, 2018 at 2:33 PM, Frank Rowand <frowand.list@xxxxxxxxx> wrote: > >> >> >>>>>>>>>> [... snip ...] > >> > [snip] > >> >> > Your implementation knows what my overlay means otherwise because I > >> >> > reference a labelled node using &foo, dtc generated a /__fixup__ for > >> >> > it, your implementation takes that /__fixup__ and does the lookup in > >> >> > the symbol table. The symbol exists and points to a node, what's the > >> >> > point of rejecting it there?> > >> >> > It seems unreasonable to me, because you cannot always control the > >> >> > source of your live tree. In many cases, sure, it's generated in-tree > >> >> > or in U-Boot and passed to you, and you can reasonably expect you > >> >> > won't encounter this. What if you have vendor-provided tree? > >> >> > > >> >> > I think the point I'm getting at is that it seems like this will have > >> >> > to change at some point anyways simply because you can't control all > >> >> > sources of your devicetree, and this isn't strictly wrong. Telling > >> >> > someone "No, we can't apply that overlay because your vendor's > >> >> > internal tool for generating dts and $other_format_used_internally > >> >> > simultaneously didn't generate a phandle for that" is kind of hard,> especially when your reasoning ISN'T "their blob is malformed" or > >> >> > "your overlay's reference is ambiguous" but rather, "we know what > >> >> > that's pointing at, but we just don't generate handles." > >> >> > >> >> No, the blob _is_ malformed. I know there is no official binding > >> >> document for overlays (we do need such things once we figure out > >> >> what we are doing), so this comment is purely my opinion. > >> > > >> > In this case it's not a spec for overlays that's the issue, it's a > >> > spec for what base trees require in order to accept overlays. > >> > > >> >> The blob is malformed because it was not compiled with the "-@" > >> >> flag. Mostly not because of anything in the source, although > >> >> again the __symbols__ node should not be hand coded. > >> > > >> > I don't think it's reasonable to claim a blob is malformed based > >> > purely on how it was generated, it needs to be something about it's > >> > actualy contents. > >> > > >> > So the question is: is "includes a phandle for every node with a > >> > symbol" a requirement for an overlay accepting base tree. It's never > >> > been explicitly stated, since overlays were just kind of hacked > >> > together rather than fully specced out. dtc has been written assuming > >> > that is a requirement, BSDdtc has not. > >> > > >> > I'm inclined to say "yes, it should be a requirement" on the grounds > >> > that: > >> > a) that's the interpretation that's more widely deployed already > >> > and > >> > b) that simplifies the overlay application logic, which generally > >> > takes place in a more restricted environment than the initial > >> > compilation. > >> > > >> > I'm entirely open to arguments against that position though. > >> > >> To be honest, I think both of these points are kind of wobbly. > > > > I'm not claiming they're conclusive, just the best arguments I've seen > > so far. > > > >> Just > >> because something has been largely interpreted a certain way does not > >> make it necessarily a good way to do so. > > > > No, but the fact that widely deployed implementations rely on a > > certain interpretation is a fairly strong argument for keeping it, > > even if it's not the best by other measures. > > > >> It's also kind of hard to make the simplification point, my latest > >> patch [1] that I run locally doesn't really touch existing stuff all > >> that much, and it certainly doesn't feel any more complex than what > >> was already there. > > > > It adds and doesn't remove code, so I think it's hard to argue it > > doesn't add complexity. > > I think we have different definitions of complexity, then. =) To me, > this isn't added complexity unless it actually entails some kind of > real re-design and work put into it. > > >> I would be inclined to say that a spec shouldn't hold a strong > >> position on this, for the following reasons: > >> > >> 1.) I've not yet seen a good technical reason for requiring explicit > >> assignment. Explicit assignment was useful when you had no other > >> method for resolving xrefs, but this isn't the case here. > > > > I'm not really sure what you mean by explicit assignment. > > Explicit assignment of phandles to a node. Um.. that didn't help. As far as I can tell we're discussing implicit assignment of phandles to nodes by the compiler, versus implicit assignment of phandles to nodes by the overlay applier. Nothing explicit about either case. -- 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
