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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 4049 bytes --]

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@bootlin.com> wrote:
> 
> > Hi David,
> > 
> > On Wed, 21 Oct 2026 13:26:49 +1100
> > David Gibson <david@gibson.dropbear.id.au> 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).

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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]