From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mitch Bradley Subject: Re: [PATCH v2 REPOST] dtc: Add support for named integer constants Date: Wed, 11 Jan 2012 14:05:28 -1000 Message-ID: <4F0E23C8.8030009@firmworks.com> References: <1323720257-23847-1-git-send-email-swarren@nvidia.com> <74CDBE0F657A3D45AFBB94109FB122FF1751860874@HQMAIL01.nvidia.com> <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5@HQMAIL01.nvidia.com> <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D@HQMAIL01.nvidia.com> <20120111130056.GK4935@truffala.fritz.box> <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5@HQMAIL01.nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Stephen Warren Cc: Devicetree Discuss List-Id: devicetree@vger.kernel.org I find it ironic that the very first device tree implementation, dating back to 1989, was built around a Turing complete language. On 1/11/2012 11:36 AM, Stephen Warren wrote: > Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM: >>> On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: >>>> John, David, >>>> >>>> What can we do to reach consensus on expanding dtc to handle named >>>> constants, or in general any future direction to extend the syntax with >>>> expressions etc.? >>> >>> Hrm, so, I'm not at all keen to add a named constant syntax without at >>> least having an outline of what a future macro/function syntax would >>> look like. >> >> Which is where I thought it was left earlier...? :-) >> And it's not just what the macro/function syntax will look like, >> but also how these will play into a more generalized expression >> handling mechanism. Defining something one-off now that doesn't >> fit well into a long term plan is less than ideal. >> >> Yes, I know that is tantamount to requiring the whole, larger >> picture be solved first. But Dave is right -- at least an outline >> of the direction. Seriously, the lexical problems can form some >> of the nastiest gotchas if we're not careful from the onset. > > So that all makes sense. > > My question is: How can we get consensus on what we want that complete > future syntax to be? IIRC, Jon has a branch that implements a proposal, > and David at least posted a different proposal if not actual code that > implemented it. We're not missing proposals, but rather a mechanism to > decide between them? > > For what it's worth, I'd tend towards a simple expression-based syntax > where property values can be calculated with C-style expressions. Basic > math stuff like ( ) + - * /& | ~<< >> and some basic string handling > operations (str(int) and concatenation). I think that'd cover the vast > majority of use-cases wouldn't it? For more advanced stuff like loops > to synthesize multiple nodes, it seems like writing a custom script to > generate the .dts file and then passing the result to dtc would be more > modular, and not require us to create a whole new Turing-complete > language in dtc? >