Return to Answer

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label. You can reference a node for two reasons (that I can think of): 1) to override the definition of the node (often in another file) or 2) link a property of one node to another node.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label. You can reference a node for two reasons (that I can think of): 1) to override the definition of the node (often in another file) or 2) link a property of one node to another node.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

FYI: a node name is unique within the children of a node -- by definition! If there are blocks that use the same node name for multiple blocks in the context of the same parent node, then the blocks are merged. On the other hand, a label must be unique across every block/node. A duplicate label results in a build error.

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label. You can reference a node for two reasons (that I can think of): 1) to override the definition of the node (often in another file) or 2) link a property of one node to another node.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: "label: name". Omit the colon if no label.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarch. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node 'a' and then modify 'a' like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.

I find the DT syntax rather confusing. The answer from Xofo is accurate but doesn't really cover all of the questions you asked.

What does it convey if a node has & as its prefix?

The ampersand is how you reference a label. A node has a name and it optionally has a label formatted as: label: name. Omit the colon if no label.

A label is only needed if you want to reference the node elsewhere ... using the ampersand syntax. Put another way, if you want to reference a node somewhere, then ensure that it has a label and then reference the label with an ampersand prefix.

What is the necessity of separating them from root node, while they can be present in the root node itself?

A node that has a name (just not a label) defines a node in the hierarchy and therefore must be inside something that specifies a position in the hierarchy. It could be in a tree of node definitions -- i.e. root node. Or it could be inside a node reference since a node reference is associated with a node definition that is at some position in the hierarchy.

A reference node should be outside of the hierarchy. IDK whether it makes sense to have a reference node inside a reference node ... probably not.

Interestingly, the above example also has two root nodes, how is that possible?

Nodes (both definitions and references) overlay; adding new info and overwriting existing. In your example, the first root defines two properties (model and compatible) and the second root adds a sub-node (hdmi) to the root.

I'll show how this stuff is useful. You could define a node a and then modify a like this:

/ { a { x = "1"; }; }; / { a { x = "2"; }; }; 

Or you could do it this way:

/ { b: a { x = "1"; }; }; &b { x = "2"; }; 

This is a trivial example, but consider that names can be longer and the hierarchy can be deeper.