[RFC PATCH 19/77] dtc: Introduce export symbols

Herve Codina posted 77 patches 3 weeks, 5 days ago
[RFC PATCH 19/77] dtc: Introduce export symbols
Posted by Herve Codina 3 weeks, 5 days ago
Export symbols allow to define a list of symbols exported at a given
node level. Those exported symbols can be used by an addon when the
addon is applied on the node exporting the symbols. In order to perform
its symbol resolution. Any unresolved phandle value will be resolved
using those exported symbols.

The feature is similar to __symbols__ involved with overlay but while
all symbols are visible with __symbols__, only specific symbols
(exported symbols) are visible with export symbols.

Also an exported symbol has a specific name and this name has to
used for symbol resolution. Having this specific name allows to:

  - Have several nodes providing the same exported symbols
    name but each of them pointing to different nodes.

    Without looking at the detail of the syntax, node-a and node-b
    export the same symbol foo but pointing to different node.
      node-a {
        /* export foo -> /path/foo1 */
      };
      node-b {
        /* export foo -> /path/foo2 */
      };

    This allow to have the exact same addon referencing 'foo' applied
    either on node-a or node-b.

  - Have several board describing a well defined node even if resources
    needed for exported symbols are not the same.

    On board A, the 'ctrl' exported symbols points to some ctrl device
    available on the SoC:
      node {
        /* export 'ctrl' -> /soc/ctrl@1000
      };

    On board B, the ctrl device used is on a i2c bus
      node {
        /* export 'ctrl' -> /soc/i2c@5000/ctrl@10
      };

    The addon can be used on board A and board B without any
    modification. It uses 'ctrl' exported by the node the it is applied
    to.

Introduce the 'symbol' internal data structure and the export symbol
list related to a node.

No functional change yet but preparation for the future support
for export symbol parsing.

Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
 dtc-parser.y |  6 +++---
 dtc.h        | 13 ++++++++++++-
 flattree.c   |  2 +-
 fstree.c     |  2 +-
 livetree.c   |  7 ++++---
 5 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/dtc-parser.y b/dtc-parser.y
index 2e152b0..9c93673 100644
--- a/dtc-parser.y
+++ b/dtc-parser.y
@@ -183,7 +183,7 @@ devicetree:
 			else if (is_ref_relative($1))
 				ERROR(&@2, "Label-relative reference %s not supported in plugin", $1);
 			$$ = add_orphan_node(
-					name_node(build_node(NULL, NULL, NULL),
+					name_node(build_node(NULL, NULL, NULL, NULL),
 						  ""),
 					$2, $1);
 		}
@@ -270,11 +270,11 @@ devicetree:
 nodedef:
 	  '{' proplist subnodes '}' ';'
 		{
-			$$ = build_node($2, $3, &@$);
+			$$ = build_node($2, $3, NULL, &@$);
 		}
 	| '{' subnodes '}' ';'
 		{
-			$$ = build_node(NULL, $2, &@$);
+			$$ = build_node(NULL, $2, NULL, &@$);
 		}
 	;
 
diff --git a/dtc.h b/dtc.h
index c0fffd2..6508694 100644
--- a/dtc.h
+++ b/dtc.h
@@ -204,6 +204,16 @@ struct label {
 	struct label *next;
 };
 
+struct symbol {
+	bool is_local;
+	char *name;
+	char *ref;
+	cell_t phandle;
+	char *fullpath;
+	struct symbol *next;
+	struct srcpos *srcpos;
+};
+
 struct bus_type {
 	const char *name;
 };
@@ -224,6 +234,7 @@ struct node {
 	char *name;
 	struct property *proplist;
 	struct node *children;
+	struct symbol *exportsymlist;
 
 	struct node *parent;
 	struct node *next_sibling;
@@ -272,7 +283,7 @@ struct property *chain_property(struct property *first, struct property *list);
 struct property *reverse_properties(struct property *first);
 
 struct node *build_node(struct property *proplist, struct node *children,
-			struct srcpos *srcpos);
+			struct symbol *exportsymlist, struct srcpos *srcpos);
 struct node *build_node_delete(struct srcpos *srcpos);
 struct node *name_node(struct node *node, const char *name);
 struct node *omit_node_if_unused(struct node *node);
diff --git a/flattree.c b/flattree.c
index bedb286..36b795d 100644
--- a/flattree.c
+++ b/flattree.c
@@ -809,7 +809,7 @@ static struct node *unflatten_tree(struct inbuf *dtbuf,
 	uint32_t offset;
 	const char *str;
 
-	node = build_node(NULL, NULL, NULL);
+	node = build_node(NULL, NULL, NULL, NULL);
 
 	flatname = flat_read_string(dtbuf);
 
diff --git a/fstree.c b/fstree.c
index 0f9a534..445ae53 100644
--- a/fstree.c
+++ b/fstree.c
@@ -19,7 +19,7 @@ static struct node *read_fstree(const char *dirname)
 	if (!d)
 		die("Couldn't opendir() \"%s\": %s\n", dirname, strerror(errno));
 
-	tree = build_node(NULL, NULL, NULL);
+	tree = build_node(NULL, NULL, NULL, NULL);
 
 	while ((de = readdir(d)) != NULL) {
 		char *tmpname;
diff --git a/livetree.c b/livetree.c
index 2a0a7ed..0050492 100644
--- a/livetree.c
+++ b/livetree.c
@@ -86,7 +86,7 @@ struct property *reverse_properties(struct property *first)
 }
 
 struct node *build_node(struct property *proplist, struct node *children,
-			struct srcpos *srcpos)
+			struct symbol *exportsymlist, struct srcpos *srcpos)
 {
 	struct node *new = xmalloc(sizeof(*new));
 	struct node *child;
@@ -95,6 +95,7 @@ struct node *build_node(struct property *proplist, struct node *children,
 
 	new->proplist = reverse_properties(proplist);
 	new->children = children;
+	new->exportsymlist = exportsymlist;
 	new->srcpos = srcpos_copy(srcpos);
 
 	for_each_child(new, child) {
@@ -248,7 +249,7 @@ struct node * add_orphan_node(struct node *dt, struct node *new_node, char *ref)
 	xasprintf(&name, "fragment@%u",
 			next_orphan_fragment++);
 	name_node(new_node, "__overlay__");
-	node = build_node(p, new_node, NULL);
+	node = build_node(p, new_node, NULL, NULL);
 	name_node(node, name);
 	free(name);
 
@@ -892,7 +893,7 @@ static struct node *build_and_name_child_node(struct node *parent, const char *n
 {
 	struct node *node;
 
-	node = build_node(NULL, NULL, NULL);
+	node = build_node(NULL, NULL, NULL, NULL);
 	name_node(node, name);
 	add_child(parent, node);
 
-- 
2.52.0
Re: [RFC PATCH 19/77] dtc: Introduce export symbols
Posted by David Gibson 3 weeks, 3 days ago
On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:
> Export symbols allow to define a list of symbols exported at a given
> node level. Those exported symbols can be used by an addon when the
> addon is applied on the node exporting the symbols.

This seems to imply an addon always applies at a single node location.
I'm not sure that's a good design choice, since I don't see how it
covers the case of something that connects to several connectors.

> In order to perform
> its symbol resolution. Any unresolved phandle value will be resolved
> using those exported symbols.
> 
> The feature is similar to __symbols__ involved with overlay but while
> all symbols are visible with __symbols__, only specific symbols
> (exported symbols) are visible with export symbols.

This paragraph doesn't make sense to me.  What's a "symbol" if it's
not something in __symbols__ or export symbols?

> Also an exported symbol has a specific name and this name has to
> used for symbol resolution. Having this specific name allows to:
> 
>   - Have several nodes providing the same exported symbols
>     name but each of them pointing to different nodes.

That's not a property of having a specific name, that's a property of
being local to a node.

>     Without looking at the detail of the syntax, node-a and node-b
>     export the same symbol foo but pointing to different node.
>       node-a {
>         /* export foo -> /path/foo1 */
>       };
>       node-b {
>         /* export foo -> /path/foo2 */
>       };
> 
>     This allow to have the exact same addon referencing 'foo' applied
>     either on node-a or node-b.
> 
>   - Have several board describing a well defined node even if resources
>     needed for exported symbols are not the same.
> 
>     On board A, the 'ctrl' exported symbols points to some ctrl device
>     available on the SoC:
>       node {
>         /* export 'ctrl' -> /soc/ctrl@1000
>       };
> 
>     On board B, the ctrl device used is on a i2c bus
>       node {
>         /* export 'ctrl' -> /soc/i2c@5000/ctrl@10
>       };
> 
>     The addon can be used on board A and board B without any
>     modification. It uses 'ctrl' exported by the node the it is applied
>     to.
> 
> Introduce the 'symbol' internal data structure and the export symbol
> list related to a node.
> 
> No functional change yet but preparation for the future support
> for export symbol parsing.
> 
> Signed-off-by: Herve Codina <herve.codina@bootlin.com>
> ---
>  dtc-parser.y |  6 +++---
>  dtc.h        | 13 ++++++++++++-
>  flattree.c   |  2 +-
>  fstree.c     |  2 +-
>  livetree.c   |  7 ++++---
>  5 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/dtc-parser.y b/dtc-parser.y
> index 2e152b0..9c93673 100644
> --- a/dtc-parser.y
> +++ b/dtc-parser.y
> @@ -183,7 +183,7 @@ devicetree:
>  			else if (is_ref_relative($1))
>  				ERROR(&@2, "Label-relative reference %s not supported in plugin", $1);
>  			$$ = add_orphan_node(
> -					name_node(build_node(NULL, NULL, NULL),
> +					name_node(build_node(NULL, NULL, NULL, NULL),
>  						  ""),
>  					$2, $1);
>  		}
> @@ -270,11 +270,11 @@ devicetree:
>  nodedef:
>  	  '{' proplist subnodes '}' ';'
>  		{
> -			$$ = build_node($2, $3, &@$);
> +			$$ = build_node($2, $3, NULL, &@$);
>  		}
>  	| '{' subnodes '}' ';'
>  		{
> -			$$ = build_node(NULL, $2, &@$);
> +			$$ = build_node(NULL, $2, NULL, &@$);
>  		}
>  	;
>  
> diff --git a/dtc.h b/dtc.h
> index c0fffd2..6508694 100644
> --- a/dtc.h
> +++ b/dtc.h
> @@ -204,6 +204,16 @@ struct label {
>  	struct label *next;
>  };
>  
> +struct symbol {
> +	bool is_local;
> +	char *name;
> +	char *ref;
> +	cell_t phandle;
> +	char *fullpath;
> +	struct symbol *next;
> +	struct srcpos *srcpos;
> +};
> +
>  struct bus_type {
>  	const char *name;
>  };
> @@ -224,6 +234,7 @@ struct node {
>  	char *name;
>  	struct property *proplist;
>  	struct node *children;
> +	struct symbol *exportsymlist;
>  
>  	struct node *parent;
>  	struct node *next_sibling;
> @@ -272,7 +283,7 @@ struct property *chain_property(struct property *first, struct property *list);
>  struct property *reverse_properties(struct property *first);
>  
>  struct node *build_node(struct property *proplist, struct node *children,
> -			struct srcpos *srcpos);
> +			struct symbol *exportsymlist, struct srcpos *srcpos);
>  struct node *build_node_delete(struct srcpos *srcpos);
>  struct node *name_node(struct node *node, const char *name);
>  struct node *omit_node_if_unused(struct node *node);
> diff --git a/flattree.c b/flattree.c
> index bedb286..36b795d 100644
> --- a/flattree.c
> +++ b/flattree.c
> @@ -809,7 +809,7 @@ static struct node *unflatten_tree(struct inbuf *dtbuf,
>  	uint32_t offset;
>  	const char *str;
>  
> -	node = build_node(NULL, NULL, NULL);
> +	node = build_node(NULL, NULL, NULL, NULL);
>  
>  	flatname = flat_read_string(dtbuf);
>  
> diff --git a/fstree.c b/fstree.c
> index 0f9a534..445ae53 100644
> --- a/fstree.c
> +++ b/fstree.c
> @@ -19,7 +19,7 @@ static struct node *read_fstree(const char *dirname)
>  	if (!d)
>  		die("Couldn't opendir() \"%s\": %s\n", dirname, strerror(errno));
>  
> -	tree = build_node(NULL, NULL, NULL);
> +	tree = build_node(NULL, NULL, NULL, NULL);
>  
>  	while ((de = readdir(d)) != NULL) {
>  		char *tmpname;
> diff --git a/livetree.c b/livetree.c
> index 2a0a7ed..0050492 100644
> --- a/livetree.c
> +++ b/livetree.c
> @@ -86,7 +86,7 @@ struct property *reverse_properties(struct property *first)
>  }
>  
>  struct node *build_node(struct property *proplist, struct node *children,
> -			struct srcpos *srcpos)
> +			struct symbol *exportsymlist, struct srcpos *srcpos)
>  {
>  	struct node *new = xmalloc(sizeof(*new));
>  	struct node *child;
> @@ -95,6 +95,7 @@ struct node *build_node(struct property *proplist, struct node *children,
>  
>  	new->proplist = reverse_properties(proplist);
>  	new->children = children;
> +	new->exportsymlist = exportsymlist;
>  	new->srcpos = srcpos_copy(srcpos);
>  
>  	for_each_child(new, child) {
> @@ -248,7 +249,7 @@ struct node * add_orphan_node(struct node *dt, struct node *new_node, char *ref)
>  	xasprintf(&name, "fragment@%u",
>  			next_orphan_fragment++);
>  	name_node(new_node, "__overlay__");
> -	node = build_node(p, new_node, NULL);
> +	node = build_node(p, new_node, NULL, NULL);
>  	name_node(node, name);
>  	free(name);
>  
> @@ -892,7 +893,7 @@ static struct node *build_and_name_child_node(struct node *parent, const char *n
>  {
>  	struct node *node;
>  
> -	node = build_node(NULL, NULL, NULL);
> +	node = build_node(NULL, NULL, NULL, NULL);
>  	name_node(node, name);
>  	add_child(parent, node);
>  
> -- 
> 2.52.0
> 
> 

-- 
David Gibson (he or they)	| 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
Re: [RFC PATCH 19/77] dtc: Introduce export symbols
Posted by Herve Codina 3 weeks, 1 day ago
Hi David,

On Thu, 15 Jan 2026 16:52:26 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:
> > Export symbols allow to define a list of symbols exported at a given
> > node level. Those exported symbols can be used by an addon when the
> > addon is applied on the node exporting the symbols.  
> 
> This seems to imply an addon always applies at a single node location.
> I'm not sure that's a good design choice, since I don't see how it
> covers the case of something that connects to several connectors.

Apply the addon on a node that knows about those connectors.

> 
> > In order to perform
> > its symbol resolution. Any unresolved phandle value will be resolved
> > using those exported symbols.
> > 
> > The feature is similar to __symbols__ involved with overlay but while
> > all symbols are visible with __symbols__, only specific symbols
> > (exported symbols) are visible with export symbols.  
> 
> This paragraph doesn't make sense to me.  What's a "symbol" if it's
> not something in __symbols__ or export symbols?

An imported symbols ?

/import/ foo "blabla";

from the addon point of view where this /import/ is present, 'foo' is a
symbol.

> 
> > Also an exported symbol has a specific name and this name has to
> > used for symbol resolution. Having this specific name allows to:
> > 
> >   - Have several nodes providing the same exported symbols
> >     name but each of them pointing to different nodes.  
> 
> That's not a property of having a specific name, that's a property of
> being local to a node.

Yes, exactly. I will reword.

Best regards,
Hervé
Re: [RFC PATCH 19/77] dtc: Introduce export symbols
Posted by David Gibson 2 weeks, 6 days ago
On Fri, Jan 16, 2026 at 05:27:35PM +0100, Herve Codina wrote:
> Hi David,
> 
> On Thu, 15 Jan 2026 16:52:26 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:
> > > Export symbols allow to define a list of symbols exported at a given
> > > node level. Those exported symbols can be used by an addon when the
> > > addon is applied on the node exporting the symbols.  
> > 
> > This seems to imply an addon always applies at a single node location.
> > I'm not sure that's a good design choice, since I don't see how it
> > covers the case of something that connects to several connectors.
> 
> Apply the addon on a node that knows about those connectors.

That seems limiting to me, because it requires the base tree to know
about all possible connector combinations, which I'm not sure is
feasible.  If I understood Geert(?)'s case properly, there are use
cases where a board might have, say, six "type foo" connectors, and an
addon board could connect to any two of those.  Of a board might have
3 "type foo" and 3 "type bar" connectors and an addon board needs to
connect to (any) of each.  It seems much more natural to me that at
attach time you say
	"addon foo 0 => board foo 1, addon foo 1 => board foo 5"
or	"addon foo 0 => board foo 2, addon bar 0 => board bar 1"

Rather than the board itself having to anticipate all combinations.

> > > In order to perform
> > > its symbol resolution. Any unresolved phandle value will be resolved
> > > using those exported symbols.
> > > 
> > > The feature is similar to __symbols__ involved with overlay but while
> > > all symbols are visible with __symbols__, only specific symbols
> > > (exported symbols) are visible with export symbols.  
> > 
> > This paragraph doesn't make sense to me.  What's a "symbol" if it's
> > not something in __symbols__ or export symbols?
> 
> An imported symbols ?
> 
> /import/ foo "blabla";
> 
> from the addon point of view where this /import/ is present, 'foo' is a
> symbol.

I guess, but existing plugin stuff doesn't really have imported
symbols, so the example doesn't really illuminate the difference from
the status quo.

> > > Also an exported symbol has a specific name and this name has to
> > > used for symbol resolution. Having this specific name allows to:
> > > 
> > >   - Have several nodes providing the same exported symbols
> > >     name but each of them pointing to different nodes.  
> > 
> > That's not a property of having a specific name, that's a property of
> > being local to a node.
> 
> Yes, exactly. I will reword.
> 
> Best regards,
> Hervé
> 

-- 
David Gibson (he or they)	| 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
Re: [RFC PATCH 19/77] dtc: Introduce export symbols
Posted by Herve Codina 2 weeks, 5 days ago
Hi David,

On Mon, 19 Jan 2026 16:51:21 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Fri, Jan 16, 2026 at 05:27:35PM +0100, Herve Codina wrote:
> > Hi David,
> > 
> > On Thu, 15 Jan 2026 16:52:26 +1100
> > David Gibson <david@gibson.dropbear.id.au> wrote:
> >   
> > > On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:  
> > > > Export symbols allow to define a list of symbols exported at a given
> > > > node level. Those exported symbols can be used by an addon when the
> > > > addon is applied on the node exporting the symbols.    
> > > 
> > > This seems to imply an addon always applies at a single node location.
> > > I'm not sure that's a good design choice, since I don't see how it
> > > covers the case of something that connects to several connectors.  
> > 
> > Apply the addon on a node that knows about those connectors.  
> 
> That seems limiting to me, because it requires the base tree to know
> about all possible connector combinations, which I'm not sure is
> feasible.  If I understood Geert(?)'s case properly, there are use
> cases where a board might have, say, six "type foo" connectors, and an
> addon board could connect to any two of those.  Of a board might have
> 3 "type foo" and 3 "type bar" connectors and an addon board needs to
> connect to (any) of each.  It seems much more natural to me that at
> attach time you say
> 	"addon foo 0 => board foo 1, addon foo 1 => board foo 5"
> or	"addon foo 0 => board foo 2, addon bar 0 => board bar 1"

Who can perform this mapping ?

The user applying the addon if a tool is used such as fdtaddon for instance
(even if this kind of mapping is not yet available in fdtaddon I proposed).

Or a driver that knows about the board connectors.

This driver will apply the addon dtb and provide custom mapping between
symbols expected by the addon (/import/) and symbols provided by the board.

> 
> Rather than the board itself having to anticipate all combinations.
> 
> > > > In order to perform
> > > > its symbol resolution. Any unresolved phandle value will be resolved
> > > > using those exported symbols.
> > > > 
> > > > The feature is similar to __symbols__ involved with overlay but while
> > > > all symbols are visible with __symbols__, only specific symbols
> > > > (exported symbols) are visible with export symbols.    
> > > 
> > > This paragraph doesn't make sense to me.  What's a "symbol" if it's
> > > not something in __symbols__ or export symbols?  
> > 
> > An imported symbols ?
> > 
> > /import/ foo "blabla";
> > 
> > from the addon point of view where this /import/ is present, 'foo' is a
> > symbol.  
> 
> I guess, but existing plugin stuff doesn't really have imported
> symbols, so the example doesn't really illuminate the difference from
> the status quo.

A plugin need to know about all possible symbols available on the board
is applied too. This is the purpose of __symbols__. This just means that for
plugin all possible symbols are imported and symbol translation is not possible.

A plugin is designed for a specific base board. It needs to know about each
busses and how they are wired.

I mean a plugin references i2c5, the i2c controller number 5, and i2c5 needs
to be present in __symbols__.

The target property in __overlay__ identify the target node. Here also, this
is dependent on the board the plugin is applied to.

Addons depend only on the node, describing the connector, they are applied
to. They do not depend on the full specific board where this connector is
available.

Two different boards can have the same connector available and a given board
can have two connectors of the same family the addon can be connected to.

Best regards,
Hervé
Re: [RFC PATCH 19/77] dtc: Introduce export symbols
Posted by David Gibson 2 weeks, 4 days ago
On Mon, Jan 19, 2026 at 02:51:20PM +0100, Herve Codina wrote:
> Hi David,
> 
> On Mon, 19 Jan 2026 16:51:21 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Fri, Jan 16, 2026 at 05:27:35PM +0100, Herve Codina wrote:
> > > Hi David,
> > > 
> > > On Thu, 15 Jan 2026 16:52:26 +1100
> > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > >   
> > > > On Mon, Jan 12, 2026 at 03:19:09PM +0100, Herve Codina wrote:  
> > > > > Export symbols allow to define a list of symbols exported at a given
> > > > > node level. Those exported symbols can be used by an addon when the
> > > > > addon is applied on the node exporting the symbols.    
> > > > 
> > > > This seems to imply an addon always applies at a single node location.
> > > > I'm not sure that's a good design choice, since I don't see how it
> > > > covers the case of something that connects to several connectors.  
> > > 
> > > Apply the addon on a node that knows about those connectors.  
> > 
> > That seems limiting to me, because it requires the base tree to know
> > about all possible connector combinations, which I'm not sure is
> > feasible.  If I understood Geert(?)'s case properly, there are use
> > cases where a board might have, say, six "type foo" connectors, and an
> > addon board could connect to any two of those.  Of a board might have
> > 3 "type foo" and 3 "type bar" connectors and an addon board needs to
> > connect to (any) of each.  It seems much more natural to me that at
> > attach time you say
> > 	"addon foo 0 => board foo 1, addon foo 1 => board foo 5"
> > or	"addon foo 0 => board foo 2, addon bar 0 => board bar 1"
> 
> Who can perform this mapping ?
> 
> The user applying the addon if a tool is used such as fdtaddon for instance
> (even if this kind of mapping is not yet available in fdtaddon I proposed).
> 
> Or a driver that knows about the board connectors.

Either or.  From the point of view of the design, I'm thinking of this
being specified by the "client" - that is by whatever is initiating
the application of the addon.  That could come directly from user
input, but in cases where the connectors are sufficiently probable,
something automated could also supply the information.

> This driver will apply the addon dtb and provide custom mapping between
> symbols expected by the addon (/import/) and symbols provided by the board.
> 
> > 
> > Rather than the board itself having to anticipate all combinations.
> > 
> > > > > In order to perform
> > > > > its symbol resolution. Any unresolved phandle value will be resolved
> > > > > using those exported symbols.
> > > > > 
> > > > > The feature is similar to __symbols__ involved with overlay but while
> > > > > all symbols are visible with __symbols__, only specific symbols
> > > > > (exported symbols) are visible with export symbols.    
> > > > 
> > > > This paragraph doesn't make sense to me.  What's a "symbol" if it's
> > > > not something in __symbols__ or export symbols?  
> > > 
> > > An imported symbols ?
> > > 
> > > /import/ foo "blabla";
> > > 
> > > from the addon point of view where this /import/ is present, 'foo' is a
> > > symbol.  
> > 
> > I guess, but existing plugin stuff doesn't really have imported
> > symbols, so the example doesn't really illuminate the difference from
> > the status quo.
> 
> A plugin need to know about all possible symbols available on the board
> is applied too. This is the purpose of __symbols__. This just means that for
> plugin all possible symbols are imported and symbol translation is not possible.
> 
> A plugin is designed for a specific base board. It needs to know about each
> busses and how they are wired.
> 
> I mean a plugin references i2c5, the i2c controller number 5, and i2c5 needs
> to be present in __symbols__.
> 
> The target property in __overlay__ identify the target node. Here also, this
> is dependent on the board the plugin is applied to.
> 
> Addons depend only on the node, describing the connector, they are applied
> to. They do not depend on the full specific board where this connector is
> available.
> 
> Two different boards can have the same connector available and a given board
> can have two connectors of the same family the addon can be connected to.

Ok, I think I see what you're getting at.

-- 
David Gibson (he or they)	| 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