[PATCH v2] dtc: Add support for named integer constants
David Gibson
david at gibson.dropbear.id.au
Fri Sep 9 11:34:33 EST 2011
On Thu, Sep 08, 2011 at 11:32:11AM -0700, Grant Likely wrote:
> On Thu, Sep 08, 2011 at 06:09:27AM -0700, Simon Glass wrote:
> > Hi Stephen,
> >
> > On Fri, Sep 2, 2011 at 11:34 AM, Stephen Warren <swarren at nvidia.com> wrote:
> > > Stephen Warren wrote at Tuesday, August 30, 2011 3:30 PM:
> > >> You may define constants as follows:
> > >>
> > >> /define/ TWO 2;
> > >> /define/ FOUR 4;
> > >> /define/ OTHER FOUR;
> > >>
> > >> And properties may use these values as follows:
> > >>
> > >> foo = <1 TWO 3 FOUR 5>;
> > >>
> > >> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> > >
> > > David, Jon,
> > >
> > > Does this seem reasonable?
> > >
> > > I think the syntax is simple enough it wouldn't interfere with any more
> > > advanced expression/function/... support in the future, and it could be
> > > easily extended to allow e.g.:
> > >
> > > /define/ FOO "BAR";
> > > /define/ BAX [0af8dacb0];
> > > ...
> >
> > This seems very reasonable to me, and very useful. From the syntax it
> > looks like lower case symbols are allowed also, which is fine with me.
> >
> > I hope that this can go into dtc as we would definitely use it.
>
> What are the risks of symbol conflict with this approach? I'm
> concerned that a poorly chosen /define/ name will break parsing in
> non-obvious ways. Would it be better to have a every define reference
> to be explicit in the syntax?
I really don't want to make identifiers - which is essentially what
we're talking here - explicitly marked, on the basis of "be like C".
I believe they should be safe, as long as we don't attempt to
recognize them in property/nodename context.
--
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
More information about the devicetree-discuss
mailing list