Re: [PATCH v3 15/15] Introduce v18 dtb version

[Herve Codina]

Hi David,

On Fri, 30 Oct 2026 13:48:25 +1100
David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:

> On Fri, Oct 30, 2026 at 01:02:28AM +0100, Herve Codina wrote:
> > Hi David,
> > 
> > I know you are busy but if you could give me your opinion on this last
> > message that would be greatly appreciated.
> > 
> > I've started to prepare the next iteration of the series adding support for
> > "structured" tags and their definition need to be stable to move forward.
> > 
> > The question to answer to complete the definition of the "structured" tag
> > format is: Should SAFE_SKIP bit be re-introduced?  
> 
> Sorry, I lost track of this one amongst all the rest of the activity.
> 
> > IMHO, it should.
> > 
> > Best regards,
> > Hervé
> > 
> > On Wed, 21 Oct 2026 15:59:23 +0200
> > Herve Codina <herve.codina@xxxxxxxxxxx> wrote:
> >   
> > > Hi David,
> > > 
> > > On Wed, 21 Oct 2026 13:26:49 +1100
> > > David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote:
> > >   
> > > > 
> > > > Correct.  Btw, I know I suggested "skippable tag" as a term, but given
> > > > how that gets kind of misleading in the case of writes, I'm coming to
> > > > prefer the orignal "structured tag" term.    
> > > 
> > > Ok, no problem to switch back to "structured tag". On my side also, I prefer
> > > this term.
> > > 
> > > Now I think that the bit indicating if a structured tag can be skip or not
> > > should be kept. I know the we can use "old" tag format when a tag cannot be
> > > skipped but I thing that using structured tags for those tags can lead to some
> > > benefit. For instance, in fdt_tag_next() we can benefit of the data size
> > > encoded for structured tags for all king of structured tags (skippable and not
> > > skippable) and retrieve the next tag without the need for parsing data related
> > > to a tag. When tag has a string as data, without the length we have to scan the
> > > string to find its end. Of course we can add the length if the tag definition
> > > but this is automatically implied if we use a structured tag.
> > > 
> > > So for structured tag, I can propose:
> > > - bit 31: 1 to identify a structured tag
> > > - bit 30: SAFE_SKIP bit (1 if we can skip, O otherwise)
> > > - bit 29..24: Data lendth encoding
> > >    0b000000: No data
> > >    0b000001: 1 32bit word of data
> > >    ...
> > >    0b111110: 63 x 32bit words data
> > >    0b111111: varlen encoding (1 32bit word added after the tag to encode the
> > >            data length in bytes.
> > > - bit 23..0: Tag id
> > >
> > > Without the SAFE_SKIP bit, all structured tags must be skippable. IMHO, we
> > > could regret this limitation in the future.
> > > 
> > > The cost of the SAFE_SKIP bit is not a lot. When we check to see if an
> > > unkwown tag can be skipped, we are going to move from
> > >   if (tag & 1<31)
> > > to
> > >   if ((tag & (1<31 | 1<<30)) == (1<31 | 1<<30))
> > > 
> > > IHMO, this is acceptable.
> > > 
> > > Of course, if the SAFE_SKIP bit is re-introduced, I will also re-add the test
> > > checking that unknown structured tag that cannot be skipped leads
> > > to an error.  
> 
> So, I'm not entirely convinced either way.  However, I have a
> semi-related thought that might sidestep the question for the time
> being.
> 
> I think it would be a good idea to leave some bits reserved, in case
> there's some more structured information we want to put in later.  One
> candidate might be "invalidated-when-X-happens" type bits which we
> considered when discussing the versioning.  I think we can spare the
> bits, since both tag and especially id fields are pretty generous at
> the moment (23 bits when our entire current existing tagset fits in 4
> bits with a bunch of spare room).

Yes, I agree.

> 
> For reserved bits to be safe to use later we must insist and enforce
> that they be 0 for now.  That means setting any reserved bit
> effectively makes it a non-skippable tag for the time being.  Or to
> put it another way, that means we can amongst other things add an
> (inverted) SAFE_SKIP bit in future if we discover we want it.
> 

Yes indeed.

The structured tag definition becomes:
 - bit 31: 1 to identify a structured tag
 - bit 30..24: Reserved (7 bits)
               Those bits are reserved for future use. They must be cleared (0 value).
               If any of these bits is set, an error should be reported.
 - bit 23..18: Data length encoding (6 bits)
     0b000000: No data
     0b000001: 1 32bit word of data
     ...
     0b111110: 62 x 32bit words data
     0b111111: varlen encoding (1 32bit word added after the tag to encode the
               data length in bytes).
 - bit 17..0: Tag id

Is this mapping ok on your side?

Best regards,
Hervé