Re: [PATCH v3 02/15] libfdt: Don't assume the root node is available at offset 0

[Herve Codina]

Hi David,

On Wed, 9 Sep 2026 16:18:22 +1000
David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:

...

> > 
> > Having a fdt_root_offset() stop at either FDT_BEGIN_NODE_REF or FDT_BEGIN_NODE
> > is "fdt_first_node_offset()".  
> 
> > Let me introduce the internal fdt_first_node_offset_()
> > - fdt_root_offset()
> >   It calls fdt_first_node_offset_() and check that this node is a
> >   FDT_BEGIN_NODE node.
> > 
> > - fdt_check_node_offset_()
> >   if the offset == 0, it updates the value with the offset returned by
> >   fdt_first_node_offset_()  
> 
> Right, that's exactly what I'd suggest.
> 
> A possible tweak would be to have fdt_check_node_offset_() only apply
> special case 0 handling if the _actual_ offset 0 doesn't look like a
> valid node offset.  Not sure if that will make things messier or
> cleaner.
> 
> > And so, a node offset 0 doesn't means the root node but the first node
> > in the dtb (root or orphan). I am totally fine with this definition.  
> 
> Right.  If you don't want that behaviour for addon dtbs, then I think
> the way to go would be to explicitly avoid all special case handling
> of 0 if the header flags an addon.  Handling addons requires new code,
> so we don't have to maintain backwards compatibliity for things that
> used 0 assuming it meant root node.
> 
> > At some point, maybe users of the API (when addon are involved) will have to
> > take care of that and perform something like:
> >   root = fdt_root_offset();
> >   fdt_get_property(fdt, root, "prop", NULL);
> > 
> > Or
> >   fdt_for_each_orphan(orphan, fdt) {
> >      fdt_get_property(fdt, orphan, "prop", NULL);
> >      ...
> >   }
> > 
> > Here also, I am totally fine with that an I already use this kind of sequence
> > in libfdt/fdt_addon.c to apply an addon on a base dtb.
> > 
> > I will introduce fdt_first_node_offset_() but let me know if you prefer
> > having fdt_first_node_offset_() introduced right now in this "structure
> > tags" series or later in the addon series.  
> 
> Either is fine; do whichever results in less code churn.
> 

Ok, I will do that.

Do you want to have an early version of that or having it in the next iteration
of the series is fine on you side ?

Of course, before sending a new iteration of the series, I am waiting for your feedback on
the "structured tags" part. This part is not going to be impacted by the "offset 0 vs real
root offset" we have discussed here and so what is available in this current series is still
valid.

Best regards,
Hervé