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

[David Gibson]

On Fri, Oct 30, 2026 at 09:27:17AM +0100, Herve Codina wrote:
> 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?

Sounds good, thanks.

-- 
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: signature.asc
Description: PGP signature