All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 REPOST] dtc: Add support for named integer constants
@ 2011-12-12 20:04 Stephen Warren
       [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Warren @ 2011-12-12 20:04 UTC (permalink / raw)
  To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
I posted this back in early September. I'd like to ask again that this
feature be merged into dtc; there are many situations where it'd allow
.dts files to be simplified.

My earlier posting was blocked by a lack of consensus on the direction
of macro/expression support in dtc. I haven't seen any move to resolve
this since. Can we please move forward with simple expression support;
it seems to be the most immediately useful aspect of any macro/
expression support. The alternative is to either continue to suffer with
unreadable integer constants, or perhaps pre-process before passing the
.dts file to dtc, thus making any macro support in dtc moot.

 dtc-lexer.l           |   13 +++++++++
 dtc-parser.y          |   73 +++++++++++++++++++++++++++++++++++++++++++++++++
 tests/Makefile.tests  |    3 +-
 tests/identifiers.c   |   44 +++++++++++++++++++++++++++++
 tests/identifiers.dts |   12 ++++++++
 tests/run_tests.sh    |    4 +++
 6 files changed, 148 insertions(+), 1 deletions(-)
 create mode 100644 tests/identifiers.c
 create mode 100644 tests/identifiers.dts

diff --git a/dtc-lexer.l b/dtc-lexer.l
index e866ea5..60a0677 100644
--- a/dtc-lexer.l
+++ b/dtc-lexer.l
@@ -28,6 +28,7 @@
 PROPNODECHAR	[a-zA-Z0-9,._+*#?@-]
 PATHCHAR	({PROPNODECHAR}|[/])
 LABEL		[a-zA-Z_][a-zA-Z0-9_]*
+IDENTIFIER	[a-zA-Z_][a-zA-Z0-9_]*
 STRING		\"([^\\"]|\\.)*\"
 WS		[[:space:]]
 COMMENT		"/*"([^*]|\*+[^*/])*\*+"/"
@@ -96,6 +97,12 @@ static int pop_input_file(void);
 			return DT_MEMRESERVE;
 		}
 
+<*>"/define/"	{
+			DPRINT("Keyword: /define/\n");
+			BEGIN_DEFAULT();
+			return DT_DEFINE;
+		}
+
 <*>{LABEL}:	{
 			DPRINT("Label: %s\n", yytext);
 			yylval.labelref = xstrdup(yytext);
@@ -103,6 +110,12 @@ static int pop_input_file(void);
 			return DT_LABEL;
 		}
 
+<V1>{IDENTIFIER} {
+			DPRINT("identifier: %s\n", yytext);
+			yylval.identifier = xstrdup(yytext);
+			return DT_IDENTIFIER;
+		}
+
 <V1>[0-9]+|0[xX][0-9a-fA-F]+      {
 			yylval.literal = xstrdup(yytext);
 			DPRINT("Literal: '%s'\n", yylval.literal);
diff --git a/dtc-parser.y b/dtc-parser.y
index 5e84a67..0558c38 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -33,6 +33,9 @@ extern void yyerror(char const *s);
 extern struct boot_info *the_boot_info;
 extern int treesource_error;
 
+static struct identifier *get_identifier(const char *s);
+static void set_identifier(const char *name, unsigned long long value);
+static unsigned long long eval_identifier(const char *name);
 static unsigned long long eval_literal(const char *s, int base, int bits);
 %}
 
@@ -40,6 +43,7 @@ static unsigned long long eval_literal(const char *s, int base, int bits);
 	char *propnodename;
 	char *literal;
 	char *labelref;
+	char *identifier;
 	unsigned int cbase;
 	uint8_t byte;
 	struct data data;
@@ -55,7 +59,9 @@ static unsigned long long eval_literal(const char *s, int base, int bits);
 
 %token DT_V1
 %token DT_MEMRESERVE
+%token DT_DEFINE
 %token <propnodename> DT_PROPNODENAME
+%token <identifier> DT_IDENTIFIER
 %token <literal> DT_LITERAL
 %token <cbase> DT_BASE
 %token <byte> DT_BYTE
@@ -113,6 +119,13 @@ memreserve:
 		}
 	;
 
+define:
+	  DT_DEFINE DT_IDENTIFIER cellval ';'
+		{
+			set_identifier($2, $3);
+		}
+	;
+
 addr:
 	  DT_LITERAL
 		{
@@ -125,6 +138,10 @@ devicetree:
 		{
 			$$ = name_node($2, "");
 		}
+	| define
+		{
+			$$ = name_node(build_node(NULL, NULL), "");
+		}
 	| devicetree '/' nodedef
 		{
 			$$ = merge_nodes($1, $3);
@@ -139,6 +156,10 @@ devicetree:
 				print_error("label or path, '%s', not found", $2);
 			$$ = $1;
 		}
+	| devicetree define
+		{
+			$$ = $1;
+		}
 	;
 
 nodedef:
@@ -265,6 +286,10 @@ cellval:
 		{
 			$$ = eval_literal($1, 0, 32);
 		}
+	| DT_IDENTIFIER
+		{
+			$$ = eval_identifier($1);
+		}
 	;
 
 bytestring:
@@ -327,6 +352,54 @@ void yyerror(char const *s) {
 	print_error("%s", s);
 }
 
+struct identifier {
+	const char *name;
+	unsigned long long value;
+	struct identifier *next;
+};
+static struct identifier *identifiers;
+
+static struct identifier *get_identifier(const char *name)
+{
+	struct identifier *identifier = identifiers;
+
+	while (identifier != NULL) {
+		if (streq(name, identifier->name))
+			return identifier;
+		identifier = identifier->next;
+	}
+
+	return NULL;
+}
+
+static void set_identifier(const char *name, unsigned long long value)
+{
+	struct identifier *identifier;
+
+	if (get_identifier(name) != NULL) {
+		print_error("redefining %s", name);
+		return;
+	}
+
+	identifier = xmalloc(sizeof(*identifier));
+	identifier->name = name;
+	identifier->value = value;
+	identifier->next = identifiers;
+	identifiers = identifier;
+}
+
+unsigned long long eval_identifier(const char *name)
+{
+	struct identifier *identifier = get_identifier(name);
+
+	if (identifier == NULL) {
+		print_error("identifier %s does not exist", name);
+		return 0;
+	}
+
+	return identifier->value;
+}
+
 static unsigned long long eval_literal(const char *s, int base, int bits)
 {
 	unsigned long long val;
diff --git a/tests/Makefile.tests b/tests/Makefile.tests
index c564e72..25d2e3c 100644
--- a/tests/Makefile.tests
+++ b/tests/Makefile.tests
@@ -15,7 +15,8 @@ LIB_TESTS_L = get_mem_rsv \
 	extra-terminating-null \
 	dtbs_equal_ordered \
 	dtb_reverse dtbs_equal_unordered \
-	add_subnode_with_nops path_offset_aliases
+	add_subnode_with_nops path_offset_aliases \
+	identifiers
 LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%)
 
 LIBTREE_TESTS_L = truncated_property
diff --git a/tests/identifiers.c b/tests/identifiers.c
new file mode 100644
index 0000000..a013d00
--- /dev/null
+++ b/tests/identifiers.c
@@ -0,0 +1,44 @@
+/*
+ * libfdt - Flat Device Tree manipulation
+ *	Testcase for /define/
+ * Copyright (C) 2011 NVIDIA, Inc.
+ * Derived from code:
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either version 2.1 of
+ * the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdint.h>
+
+#include <fdt.h>
+#include <libfdt.h>
+
+#include "tests.h"
+#include "testdata.h"
+
+int main(int argc, char *argv[])
+{
+	void *fdt;
+
+	test_init(argc, argv);
+	fdt = load_blob_arg(argc, argv);
+
+	check_property_cell(fdt, 0, "var1", TEST_VALUE_1);
+	check_property_cell(fdt, 0, "var2", TEST_VALUE_1);
+
+	PASS();
+}
diff --git a/tests/identifiers.dts b/tests/identifiers.dts
new file mode 100644
index 0000000..e8d8e23
--- /dev/null
+++ b/tests/identifiers.dts
@@ -0,0 +1,12 @@
+/dts-v1/;
+
+/define/ VAR1 0xdeadbeef;
+/define/ VAR2 VAR1;
+
+/ {
+	var1 = <VAR1>;
+	var2 = <VAR2>;
+};
+
+/define/ OTHER 0xdeadbeef;
+
diff --git a/tests/run_tests.sh b/tests/run_tests.sh
index 72dda32..e0da087 100755
--- a/tests/run_tests.sh
+++ b/tests/run_tests.sh
@@ -343,6 +343,10 @@ dtc_tests () {
     run_dtc_test -I dtb -O dts -o stdin_odts_test_tree1.dtb.test.dts - < test_tree1.dtb
     run_wrap_test cmp stdin_odts_test_tree1.dtb.test.dts odts_test_tree1.dtb.test.dts
 
+    # Test identifiers
+    run_dtc_test -I dts -O dtb -o identifiers.dtb identifiers.dts
+    run_test identifiers identifiers.dtb
+
     # Check for graceful failure in some error conditions
     run_sh_test dtc-fatal.sh -I dts -O dtb nosuchfile.dts
     run_sh_test dtc-fatal.sh -I dtb -O dtb nosuchfile.dtb
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
@ 2011-12-12 20:19   ` Simon Glass
       [not found]     ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Simon Glass @ 2011-12-12 20:19 UTC (permalink / raw)
  To: Stephen Warren; +Cc: Devicetree Discuss

Hi Stephen,

On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> I posted this back in early September. I'd like to ask again that this
> feature be merged into dtc; there are many situations where it'd allow
> .dts files to be simplified.

Yes I agree, it is very useful.

I get conflicts with this - does it need a rebase?

Regards,
Simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]     ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2011-12-12 20:23       ` Stephen Warren
       [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Warren @ 2011-12-12 20:23 UTC (permalink / raw)
  To: Simon Glass; +Cc: Devicetree Discuss

Simon Glass wrote at Monday, December 12, 2011 1:19 PM:
> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > ---
> > I posted this back in early September. I'd like to ask again that this
> > feature be merged into dtc; there are many situations where it'd allow
> > .dts files to be simplified.
> 
> Yes I agree, it is very useful.
> 
> I get conflicts with this - does it need a rebase?

Yes, I should have mentioned this patch is still based on the same commit
it was 3 months ago, and HEAD has moved forward since. If it's deemed
conceptually acceptable, I'll rebase it to HEAD.

(For reference, it's based on ed8fee1 "Add missing tests to .gitignore".)

-- 
nvpublic

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
@ 2012-01-04  0:46           ` Simon Glass
       [not found]             ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Simon Glass @ 2012-01-04  0:46 UTC (permalink / raw)
  To: Stephen Warren; +Cc: Devicetree Discuss

Hi Stephen,

On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> Simon Glass wrote at Monday, December 12, 2011 1:19 PM:
>> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
>> > 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> > ---
>> > I posted this back in early September. I'd like to ask again that this
>> > feature be merged into dtc; there are many situations where it'd allow
>> > .dts files to be simplified.
>>
>> Yes I agree, it is very useful.
>>
>> I get conflicts with this - does it need a rebase?
>
> Yes, I should have mentioned this patch is still based on the same commit
> it was 3 months ago, and HEAD has moved forward since. If it's deemed
> conceptually acceptable, I'll rebase it to HEAD.
>
> (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".)
>
> --
> nvpublic
>

I haven't seen any other comments. Is this going in? Constants would be useful.

Regards,
Simon

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]             ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
@ 2012-01-05 21:27               ` Stephen Warren
       [not found]                 ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Warren @ 2012-01-05 21:27 UTC (permalink / raw)
  To: Simon Glass, Jon Loeliger, David Gibson; +Cc: Devicetree Discuss

Simon Glass wrote at Tuesday, January 03, 2012 5:46 PM:
> On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > Simon Glass wrote at Monday, December 12, 2011 1:19 PM:
> >> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> >> > 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >> > ---
> >> > I posted this back in early September. I'd like to ask again that this
> >> > feature be merged into dtc; there are many situations where it'd allow
> >> > .dts files to be simplified.
> >>
> >> Yes I agree, it is very useful.
> >>
> >> I get conflicts with this - does it need a rebase?
> >
> > Yes, I should have mentioned this patch is still based on the same commit
> > it was 3 months ago, and HEAD has moved forward since. If it's deemed
> > conceptually acceptable, I'll rebase it to HEAD.
> >
> > (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".)
> 
> I haven't seen any other comments. Is this going in? Constants would be useful.

I took a quick look at rebasing this on HEAD today. There are some non-
trivial conflicts with Anton's recent patch to support variable-sized
elements in arrays. In particular, my patch relied on the cellval token,
allowing it to reference a symbol or a literal, but Anton's patch has
removed that token from the grammar.

So, I'm still willing to rebase my patch, but given the non-trivial nature
of doing so, I'd like prior confirmation from Jon and David that the syntax
is acceptable, and so my work won't be in vain.

For reference, here's the test .dts file from my patch:

+/dts-v1/;
+
+/define/ VAR1 0xdeadbeef;
+/define/ VAR2 VAR1;
+
+/ {
+	var1 = <VAR1>;
+	var2 = <VAR2>;
+};
+
+/define/ OTHER 0xdeadbeef;

-- 
nvpublic

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                 ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
@ 2012-01-10 21:54                   ` Stephen Warren
       [not found]                     ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Stephen Warren @ 2012-01-10 21:54 UTC (permalink / raw)
  To: Simon Glass, Jon Loeliger, David Gibson; +Cc: Devicetree Discuss

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.?

Will either of you be attending Linaro Connect or ELC 2012 in February
by any chance? We could get together and talk this through in person if
you are...

Thanks for any kind of discussion!

Stephen Warren wrote at Thursday, January 05, 2012 2:27 PM:
> Simon Glass wrote at Tuesday, January 03, 2012 5:46 PM:
> > On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > > Simon Glass wrote at Monday, December 12, 2011 1:19 PM:
> > >> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > >> > 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> > >> > ---
> > >> > I posted this back in early September. I'd like to ask again that this
> > >> > feature be merged into dtc; there are many situations where it'd allow
> > >> > .dts files to be simplified.
> > >>
> > >> Yes I agree, it is very useful.
> > >>
> > >> I get conflicts with this - does it need a rebase?
> > >
> > > Yes, I should have mentioned this patch is still based on the same commit
> > > it was 3 months ago, and HEAD has moved forward since. If it's deemed
> > > conceptually acceptable, I'll rebase it to HEAD.
> > >
> > > (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".)
> >
> > I haven't seen any other comments. Is this going in? Constants would be useful.
> 
> I took a quick look at rebasing this on HEAD today. There are some non-
> trivial conflicts with Anton's recent patch to support variable-sized
> elements in arrays. In particular, my patch relied on the cellval token,
> allowing it to reference a symbol or a literal, but Anton's patch has
> removed that token from the grammar.
> 
> So, I'm still willing to rebase my patch, but given the non-trivial nature
> of doing so, I'd like prior confirmation from Jon and David that the syntax
> is acceptable, and so my work won't be in vain.
> 
> For reference, here's the test .dts file from my patch:
> 
> +/dts-v1/;
> +
> +/define/ VAR1 0xdeadbeef;
> +/define/ VAR2 VAR1;
> +
> +/ {
> +	var1 = <VAR1>;
> +	var2 = <VAR2>;
> +};
> +
> +/define/ OTHER 0xdeadbeef;

-- 
nvpublic

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                     ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
@ 2012-01-11 13:00                       ` David Gibson
       [not found]                         ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: David Gibson @ 2012-01-11 13:00 UTC (permalink / raw)
  To: Stephen Warren; +Cc: Devicetree Discuss

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.  The latter is almost certain to permit the former as a
subcase, and I'd really rather not end up with two different syntaxes
for constants.

Unfortunately, much as I'd like to get all these extended features
into dtc, it's not my main job, so I don't have a lot of time to
ponder the possibilities.

> Will either of you be attending Linaro Connect or ELC 2012 in February
> by any chance? We could get together and talk this through in person if
> you are...

Not for me, I'm afraid.

-- 
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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                         ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
@ 2012-01-11 14:38                           ` Jon Loeliger
       [not found]                             ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Jon Loeliger @ 2012-01-11 14:38 UTC (permalink / raw)
  To: David Gibson; +Cc: Devicetree Discuss

> 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.

> The latter is almost certain to permit the former as a subcase, and
> I'd really rather not end up with two different syntaxes for
> constants.

Exactly.

> Unfortunately, much as I'd like to get all these extended features
> into dtc,

Agreed....

> > Will either of you be attending Linaro Connect or ELC 2012 in February
> > by any chance? We could get together and talk this through in person if
> > you are...
> 
> Not for me, I'm afraid.

Only if they are in Austin. :-)  Which is to say "Sorry, no."

jdl

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                             ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org>
@ 2012-01-11 21:36                               ` Stephen Warren
       [not found]                                 ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  2012-01-11 22:10                               ` David VomLehn (dvomlehn)
  1 sibling, 1 reply; 16+ messages in thread
From: Stephen Warren @ 2012-01-11 21:36 UTC (permalink / raw)
  To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss

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?

-- 
nvpublic

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                             ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org>
  2012-01-11 21:36                               ` Stephen Warren
@ 2012-01-11 22:10                               ` David VomLehn (dvomlehn)
       [not found]                                 ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org>
  1 sibling, 1 reply; 16+ messages in thread
From: David VomLehn (dvomlehn) @ 2012-01-11 22:10 UTC (permalink / raw)
  To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss

Even if everyone can't make it, how about a BoF session at ELC 2012? I
haven't had any time to contribute recently, but am tremendously
interested in moving this forward.

> -----Original Message-----
> From: devicetree-discuss-bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
>
[mailto:devicetree-discuss-bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org]
> On Behalf Of Jon Loeliger
> Sent: Wednesday, January 11, 2012 6:38 AM
> To: David Gibson
> Cc: Devicetree Discuss
> Subject: Re: [PATCH v2 REPOST] dtc: Add support for named integer
> constants
> 
> > 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.
> 
> > The latter is almost certain to permit the former as a subcase, and
> > I'd really rather not end up with two different syntaxes for
> > constants.
> 
> Exactly.
> 
> > Unfortunately, much as I'd like to get all these extended features
> > into dtc,
> 
> Agreed....
> 
> > > Will either of you be attending Linaro Connect or ELC 2012 in
> February
> > > by any chance? We could get together and talk this through in
> person if
> > > you are...
> >
> > Not for me, I'm afraid.
> 
> Only if they are in Austin. :-)  Which is to say "Sorry, no."
> 
> jdl
> _______________________________________________
> devicetree-discuss mailing list
> devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                 ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
@ 2012-01-12  0:05                                   ` Mitch Bradley
       [not found]                                     ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
  2012-01-16  1:54                                   ` David Gibson
  1 sibling, 1 reply; 16+ messages in thread
From: Mitch Bradley @ 2012-01-12  0:05 UTC (permalink / raw)
  To: Stephen Warren; +Cc: Devicetree Discuss

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?
>

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                     ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
@ 2012-01-12 14:11                                       ` Jon Loeliger
  0 siblings, 0 replies; 16+ messages in thread
From: Jon Loeliger @ 2012-01-12 14:11 UTC (permalink / raw)
  To: Mitch Bradley; +Cc: Devicetree Discuss

> I find it ironic that the very first device tree implementation, dating 
> back to 1989, was built around a Turing complete language.

...and that my uncle wrote one of the very first
books about that language. :-)

jdl

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                 ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org>
@ 2012-01-13  7:00                                   ` Shawn Guo
  0 siblings, 0 replies; 16+ messages in thread
From: Shawn Guo @ 2012-01-13  7:00 UTC (permalink / raw)
  To: David VomLehn (dvomlehn); +Cc: Devicetree Discuss

On Wed, Jan 11, 2012 at 04:10:52PM -0600, David VomLehn (dvomlehn) wrote:
> Even if everyone can't make it, how about a BoF session at ELC 2012? I
> haven't had any time to contribute recently, but am tremendously
> interested in moving this forward.
> 
+1

We've been wanting this support for long time.

-- 
Regards,
Shawn

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                 ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  2012-01-12  0:05                                   ` Mitch Bradley
@ 2012-01-16  1:54                                   ` David Gibson
       [not found]                                     ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
  1 sibling, 1 reply; 16+ messages in thread
From: David Gibson @ 2012-01-16  1:54 UTC (permalink / raw)
  To: Stephen Warren; +Cc: Devicetree Discuss

On Wed, Jan 11, 2012 at 01:36:46PM -0800, 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?

Um.. try to make a detailed proposal (synthesised from earlier ones)
that enough people are happy with (Jon and myself for starters).

> 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?

Well.. that's not entirely true.  The proposed expression syntax was
essentially identical between Jon's proposal and mine (though the
implementation of it is quite different).  Jon's proposal includes
loops and "functions", mine started with just expressions.  I had in
mind some sort of macro language to allow making use of those
expressions.  I'm not sure quite what that would look like (or even if
it would be implemented withing dtc, or use an external helper like
cpp).  So there's really only one proposal that covers the full space,
it's just I don't like it that much.

> 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).

Ok.  Well, I should de-bitrot and re-propose my integer expression
patch, which covered most of that.  I also intended basic string
operations as you suggest, though I can't remember if I made a start
on that.

I think applying that would be reasonably safe as it is.  If we go
with Jon's proposal or something like it in the end, we'll need to
reimplement most of the expression evaluation (to do delayed instead
of parse-time evaluation).  But I'm much less worried about having to
rework code - even substantially - than I am about user-visible syntax
regressions.

> I think that'd cover the vast
> majority of use-cases wouldn't it?

Not quite.  Expressions are interesting of themselves, but not all
that useful.  It's functions or macros plus expressions which gets us
close to where we want to be.  So expressions gives a little as it is,
a lot more for people already running their dts through cpp.  To
really make progress, we still want a proposal for a standard function
or macro syntax for dtc.  And, obviously, a decision whether to go
with functions or macros.  I like macros, because I think they give a
lot of flexibility with minimal conceptual complexity.  Jon's proposal
is based on functions.  I didn't like his proposal very much as a
whole, but I should take another look and see what I think of the
function syntax in isolation.

> 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?

Perhaps.  One of the reasons that I'm so doggedly conservative and
picky about new dtc syntax is that small languages have a tendency to
grow to Turing completeness, whether you intend it originally or not.
I'm ok with that happening, but I'd really like to make sure that when
and if it happens, we arrive at a decent Turing complete language, not
a horrible one.

-- 
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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                     ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
@ 2012-01-16 14:41                                       ` Jon Loeliger
       [not found]                                         ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org>
  0 siblings, 1 reply; 16+ messages in thread
From: Jon Loeliger @ 2012-01-16 14:41 UTC (permalink / raw)
  To: David Gibson; +Cc: Devicetree Discuss

> 
> > 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 applying that would be reasonably safe as it is.  If we go
> with Jon's proposal or something like it in the end, we'll need to
> reimplement most of the expression evaluation (to do delayed instead
> of parse-time evaluation).  But I'm much less worried about having to
> rework code - even substantially - than I am about user-visible syntax
> regressions.

Even with that piece, there are substanial lexical and parsing
issues that complicate things.  Bare numbers, or expressions,
next to each other without syntactic glue can cause parsing fits. :-)

> > I think that'd cover the vast
> > majority of use-cases wouldn't it?
> 
> Not quite.  Expressions are interesting of themselves, but not all
> that useful.  It's functions or macros plus expressions which gets us
> close to where we want to be.  So expressions gives a little as it is,

That's the difficult and slippery slope here.  Being able to write
    (FOO << (12 + 2))
is nice, but it would be nicer and more useful to represent
    (FOO << ((i) + 2))
where (i) was actually parameterized or iterated in some way.

> a lot more for people already running their dts through cpp.  To
> really make progress, we still want a proposal for a standard function
> or macro syntax for dtc.  And, obviously, a decision whether to go
> with functions or macros.  I like macros, because I think they give a
> lot of flexibility with minimal conceptual complexity.  Jon's proposal
> is based on functions.  I didn't like his proposal very much as a
> whole, but I should take another look and see what I think of the
> function syntax in isolation.

It might also be instructive to isolate my expression parsing
for its lexical and syntactic changes and work towards introducing
those, perhaps in isolation, as a first step.

The key there WRT your interest, Stephen, is that it can capture
the use of apparent variables or #define'd-equivalent symbols within
the expression handling.  (David's version did not.)

> > 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?
> 
> Perhaps. 

OK.  Let's explore that approach.  We'll write a, say, Python collection
of code-objects for each, what?, device.  Place them all in a large library.
Your "device tree source" effectively now becomes a "main" that starts
instantiating librarified devices, adding a litle glue to emit some
one-off property or two.

That could work.  But is it now OK that the construction of the device
tree source file is tied to Python?  Do we make the kernel builds now
reliant upon Python too?  Or Perl?  But wasn't that shot down *again*?
Hans wants shell.  Lotte likes Lua.  Suki plays with Python.  Willi
is happy again.  Adolf builds his DTS with Perl.  No one uses Tcl.
Everyone just checks-in their *generated* DTS results anyway.  It'll
be a war without tears.

Or how do you see this working?

> .. One of the reasons that I'm so doggedly conservative and
> picky about new dtc syntax is that small languages have a tendency to
> grow to Turing completeness, whether you intend it originally or not.

Isn't that someone's observation...?  Behind every flat-file there is
a Turing-complete language trying to get out.

> I'm ok with that happening, but I'd really like to make sure that when
> and if it happens, we arrive at a decent Turing complete language, not
> a horrible one.

Name two decent ones. :-)  C and ..., and ....  See?  There isn't another!

Never mind.

jdl

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants
       [not found]                                         ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org>
@ 2012-01-21 21:56                                           ` David Gibson
  0 siblings, 0 replies; 16+ messages in thread
From: David Gibson @ 2012-01-21 21:56 UTC (permalink / raw)
  To: Jon Loeliger; +Cc: Devicetree Discuss

On Mon, Jan 16, 2012 at 08:41:22AM -0600, Jon Loeliger wrote:
> > 
> > > 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 applying that would be reasonably safe as it is.  If we go
> > with Jon's proposal or something like it in the end, we'll need to
> > reimplement most of the expression evaluation (to do delayed instead
> > of parse-time evaluation).  But I'm much less worried about having to
> > rework code - even substantially - than I am about user-visible syntax
> > regressions.
> 
> Even with that piece, there are substanial lexical and parsing
> issues that complicate things.  Bare numbers, or expressions,
> next to each other without syntactic glue can cause parsing fits. :-)

Well, my patch requires that expressions in cell lists have parens
around them.  I think that's the only sane choice, otherwise there's
no reasonable way to distinguish between the 1 cell construct
<(500-300)> and the 2 cell construct <500 (-300)>.

> > > I think that'd cover the vast
> > > majority of use-cases wouldn't it?
> > 
> > Not quite.  Expressions are interesting of themselves, but not all
> > that useful.  It's functions or macros plus expressions which gets us
> > close to where we want to be.  So expressions gives a little as it is,
> 
> That's the difficult and slippery slope here.  Being able to write
>     (FOO << (12 + 2))
> is nice, but it would be nicer and more useful to represent
>     (FOO << ((i) + 2))
> where (i) was actually parameterized or iterated in some way.

Right, exactly my point.

> > a lot more for people already running their dts through cpp.  To
> > really make progress, we still want a proposal for a standard function
> > or macro syntax for dtc.  And, obviously, a decision whether to go
> > with functions or macros.  I like macros, because I think they give a
> > lot of flexibility with minimal conceptual complexity.  Jon's proposal
> > is based on functions.  I didn't like his proposal very much as a
> > whole, but I should take another look and see what I think of the
> > function syntax in isolation.
> 
> It might also be instructive to isolate my expression parsing
> for its lexical and syntactic changes and work towards introducing
> those, perhaps in isolation, as a first step.

Right.  I think my expression code and your expression code were
essentially identical syntactically (possibly modulo a slightly
different set of implemented operators).

> The key there WRT your interest, Stephen, is that it can capture
> the use of apparent variables or #define'd-equivalent symbols within
> the expression handling.  (David's version did not.)

True, but constant definitions (as opposed to function definitions)
would be trivial to add to my code.

> > > 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?
> > 
> > Perhaps. 
> 
> OK.  Let's explore that approach.  We'll write a, say, Python collection
> of code-objects for each, what?, device.  Place them all in a large library.
> Your "device tree source" effectively now becomes a "main" that starts
> instantiating librarified devices, adding a litle glue to emit some
> one-off property or two.
> 
> That could work.  But is it now OK that the construction of the device
> tree source file is tied to Python?  Do we make the kernel builds now
> reliant upon Python too?  Or Perl?  But wasn't that shot down *again*?
> Hans wants shell.  Lotte likes Lua.  Suki plays with Python.  Willi
> is happy again.  Adolf builds his DTS with Perl.  No one uses Tcl.
> Everyone just checks-in their *generated* DTS results anyway.  It'll
> be a war without tears.
> 
> Or how do you see this working?
> 
> > .. One of the reasons that I'm so doggedly conservative and
> > picky about new dtc syntax is that small languages have a tendency to
> > grow to Turing completeness, whether you intend it originally or not.
> 
> Isn't that someone's observation...?  Behind every flat-file there is
> a Turing-complete language trying to get out.
> 
> > I'm ok with that happening, but I'd really like to make sure that when
> > and if it happens, we arrive at a decent Turing complete language, not
> > a horrible one.
> 
> Name two decent ones. :-)  C and ..., and ....  See?  There isn't another!
> 
> Never mind.
> 
> jdl
> 

-- 
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

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2012-01-21 21:56 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-12 20:04 [PATCH v2 REPOST] dtc: Add support for named integer constants Stephen Warren
     [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-12-12 20:19   ` Simon Glass
     [not found]     ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-12-12 20:23       ` Stephen Warren
     [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-04  0:46           ` Simon Glass
     [not found]             ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-01-05 21:27               ` Stephen Warren
     [not found]                 ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-10 21:54                   ` Stephen Warren
     [not found]                     ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-11 13:00                       ` David Gibson
     [not found]                         ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-01-11 14:38                           ` Jon Loeliger
     [not found]                             ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org>
2012-01-11 21:36                               ` Stephen Warren
     [not found]                                 ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2012-01-12  0:05                                   ` Mitch Bradley
     [not found]                                     ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-01-12 14:11                                       ` Jon Loeliger
2012-01-16  1:54                                   ` David Gibson
     [not found]                                     ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2012-01-16 14:41                                       ` Jon Loeliger
     [not found]                                         ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org>
2012-01-21 21:56                                           ` David Gibson
2012-01-11 22:10                               ` David VomLehn (dvomlehn)
     [not found]                                 ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org>
2012-01-13  7:00                                   ` Shawn Guo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.