On Fri, Sep 9, 2011 at 12:25 AM, David Gibson <da...@gibson.dropbear.id.au> wrote: > On Thu, Sep 08, 2011 at 11:30:42PM -0700, Anton Staaf wrote: >> On Thu, Sep 8, 2011 at 6:01 AM, David Gibson >> <da...@gibson.dropbear.id.au> wrote: >> > On Thu, Sep 08, 2011 at 12:07:16AM -0700, Grant Likely wrote: >> >> On Thu, Sep 08, 2011 at 01:51:49PM +1000, David Gibson wrote: >> >> > On Wed, Sep 07, 2011 at 04:15:40PM -0700, Anton Staaf wrote: >> >> > > With this patch the following property assignment: >> >> > > >> >> > > property = ['a' 2b '\r']; >> >> > > >> >> > > is equivalent to: >> >> > > >> >> > > property = [61 2b 0d]; >> >> > >> >> > So, I still have some reservations about this syntax. >> >> > >> >> > It occurred to me: do you actually need to intermix character and >> >> > hexbyte values that much? Could I suggest an alternate sytax as: >> >> > >> >> > property = 'a', [2b], 'r'; >> >> > >> >> > The new character literals sufficiently distinct not to cause problems >> >> > here, and it maintains the , == bytestring append behaviour we already >> >> > have. >> >> > >> >> > Thoughts? >> >> >> >> Does it matter much? I'm happy with either. Is there a downside to >> >> the first syntax? >> > >> > Well.. probably not. I'm just nervous about adding anything in the >> > lexically weird bytestring context. >> >> Which is completely understandable. Let's continue to mull that over >> while we think up a sane syntax for specifying the size of a cell in a >> cell list. Would it be reasonable to specify the size per list? > > That was what I had in mind. > >> Or >> would you like to have a mechanism and syntax to specify it per cell >> entry in the list. If it is per cell entry then we have to deal with >> the strange packings that would come from something like: >> >> property = <0x11223344 byte(0x55) 0x66778899> >> >> I'm not suggesting that the byte(...) syntax be used by the way. :) >> But the above situation would lead to a value of 0x55667788 and a >> trailing 0x99, which then has to be either promoted to a uint32_t > > Well.. only if you're now interpreting the property as an array of > u32s, which if you specified it with that byte in the middle, is > presumably not how this property is typically interpreted. > >> because it was originally in a uint32_t literal, or left as a byte, >> not very obvious. The other option would be to do some sort of local >> packing. Where the above would turn into the same as: > >> property = <0x11223344 0x55 0x66778899> > > Um, I'm really not sure what you're getting at with this one. > >> But that has all sorts of problems. When do you start a new uint32_t >> cell. If it's only when you overflow out of the current one or when >> you see a full uint32_t literal then you could split a uint16_t across >> a cell boundary. > > So, I have it on Mitch Bradley's authority, that the properties should > in general be treated as bytestrings and that we should *never* do > padding in there for the sake of alignment. > >> I suppose this problem already exists because of the >> "," syntax. And so you could make a cell list that contains a bunch >> of uint32_t values that are stored in a property in such a way as to >> be unaligned. > > Yes, and intentionally so. Way back, we used to always 4-byte align > at the beginning of a cell list, but I took that out on Mitch's advice > (plus it was easier that way). I believe there are some bindings out > there (though they don't seem to be in common, current use) than > define properties to contain a string followed by cells, which will > lead to unaligned cell values. > >> The alternative of specifying the size of the cells in a list seems >> cleaner to me. You still can generate unaligned values in a property >> using ",", but within a cell list you can't. So then what would be a >> good syntax for that. Perhaps: > > I concur. > >> property = !uint16 <0x12 0x3456> >> >> or >> >> property = !uint8 <0xff 0xaa> >> >> or to explicitly get the default uint32_t behavior >> >> property = !uint32 <0x12345678 0 12> > > Well, I think this is better than anything I've yet considered, though > still not quite good enough. > >> This has the advantage that ! is not currently used in any of the dts >> syntax. And having it at the front of the cell list definition means >> that you can check and correctly pack/append each literal as they are >> read. It has the disadvantage that if we want to use ! to mean >> logical not at some point it will complicate that parsing. > > Yeah, and I'd really prefer not to make life difficult for > implementing expressions. So, some vague, and possibly contradictory > points on this topic: > > * If we can do it in a way that's not too verbose, I'd prefer both > a marker for the size present at both < and >, so that on a big array > a human has an extra visual clue that this is an array of non-default > size. > > * I've toyed with the idea of different bracketing types for the > different sizes. e.g. << >> for 64-bit values, and, uh, something for > 8 and 16. Haven't come up with any variants on this that don't seem > excessively brief and cryptic, though. > > * Also contemplated something like <$8 0xff 0x00 > or <.8 0xff 0x00> > for 8-bit values, but it seems pretty ugly. > > I supposed modifying your suggestion, but combining with our existing > convention for "reserved words" we could do: > > prop = /uint8/ <0xab 0xcd>; > > I don't love it, but it's about the best I've come up with yet. And > in particular it's probably the variant I'd be least upset to carry > around as legacy if we come up with a better way in future.
Yes, I like this better than my suggestions of using !. I wasn't sure if the /.../ syntax was something that was going to be allowed in property definitions. One other option working from this could be: property = /size/ 8 <0xab 0xcd>; It has the advantage of limiting the number of reserved words created. It could also be: property = /type/ uint8 <0xab 0xcd>; Which would allow us to define new types for cell lists without adding new syntax. I'm not sure if this is too useful though because the only types that I can think of that are not summed up by their size are things like float and double... But it does have a nice look to it in my opinion. And I would assume that if the /type/ <typename> was left off it would default to a uint32_t cell list. So the additional verbosity of having to indicate it's a different type and what the type is will only be needed in a few instances. -Anton > -- > 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 > _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss