On Tue, Oct 07, 2008 at 12:41:03PM +1100, David Gibson wrote: > > Instead of /addnode/, how about an alternate version of (or option to) > > /merge/ that merges the second tree with the contents of the first, > > Um.. I don't entirely see how this variant of /merge/ would differ > from /addnode/.
/addnode/ can only add one node at a time, and has an different syntax than normal for representing the node to be added (name is split from body). /mergeunder/ could add any number of nodes and/or properties, and would use more normal syntax. > > rather than treating the trees as sharing a root? This could also > > supersede /setprop/, if conflicts are defined to be resolved in favor of > > the second tree. > > True, and I was assuming /merge/ would resolve conflicts in favour of > one of the trees. As I said, these suggestions are only an outline - > I'm not entirely sure what we need by way of node expressions. Understood -- I was just trying to help refine the suggestion. I think the ideal way forward involves elements of both your proposal and Jon's. > > > It's possible to do this just with the /setprop/, /addnode/ operators > > > described above, but that's awkward and verbose, so allowing > > > expressions in the same place the property/node names go now seems > > > better. jdl's patch series allows this, but I'm not sure what makes > > > the grammatical distinction between the parser expecting a bare node > > > name and an expression, which worries me. > > > > I think it's the leading backslash before identifiers that distinguishes > > it. > > Uh.. this doesn't make sense, an expression doesn't have to contain > identifiers (constant expressions). It's not nonsensical, just incomplete -- I was assuming that it was obvious that quote-marks differentiate string constants. Integer constants would need parentheses in that context, though. > Actually I suspect it's the presence of quotes which does the trick, > at least in the examples Jon's given. > > > > What I would suggest here is that expressions for node/property names > > > must be parenthesized. ( and ) aren't used in node/property names > > > either in theory or practice AFAIK and this is consistent with integer > > > expressions having to be parenthesized within cell lists to avoid > > > ambiguity. > > > > I'd rather have an identifier prefix than to require parentheses in > > otherwise unambiguous contexts (which would basically amount to needing > > both a prefix and a suffix). This applies to cell context as well. > > As above, this doesn't work. It doubly doesn't work for cell context, > because we need to disambiguate <3 (-2)> (2 cells) from <(3-2)> (1 cell). It was a bare identifier (or function call) that I had in mind as a non-ambiguous context, though I can see how allowing that might complicate the implementation a little -- and allowing things like 3*2 to be unparenthesized would be even more complex. We probably should have added comma-delimiting when we switched to decimal-by-default. > Ah, yes, this is something I had a plan for, way back. I wanted to > keep the [...] construct as a being a very compact representation of > bytestrings - bytestring literals effectively. That means bare hex > and no expressions (because expressions and bare hex are a highly > confusing mix as we've discovered). But, I was intending to extend > the celllist construct to allow the "cells" to be of different sizes - > this would be useful for dealing with 64-bit quantities too. Not sure > how to do the syntax, though Possibly: > <.1 0xab 0xcd > (1 byte entries) > <.8 0xdeadbeef00000000 > (8 byte entries) > Defaulting to .4, of course. I'm not over fond of that though. > Better suggestions welcome. Seems reasonable. -Scott _______________________________________________ devicetree-discuss mailing list [email protected] https://ozlabs.org/mailman/listinfo/devicetree-discuss
