Re: [PATCH v3 06/15] Introduce structured tag value definition

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

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

On Mon, Sep 14, 2026 at 12:19:37PM +0200, Herve Codina wrote:
> Hi David,
> 
> On Sat, 12 Sep 2026 12:34:24 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> ...
> 
> > > Do you mean that we should avoid the DATA_LEN_ENCODING and always have the
> > > 32-bit value right after the tag to give the size for all "skippable" tags?  
> > 
> > Yes.
> > 
> 
> I did a test using a dts file available in kernel sources. I used (arbitrary
> choice) juno.dts [0].
> 
> Without any new tags, the size of the compiled dtb is 27067 bytes.
> 
> With new metadata tags identifying phandles in properties (FDT_PROPDATA_PHANDLE),
> the size of the dtb becomes 29027 bytes and so 29027 - 27067 = 1960 bytes for
> those FDT_PROPDATA_PHANDLE tags (+7.2%).
> 
> The tags used are composed of:
> 32-bit: FDT_PROPDATA_PHANDLE value encoding 1 x 32-bit for data
> 32-bit: offset in the property where a phandle is present.
> 
> Removing the '1 x 32-bit' information from the tag value and adding a 32-bit
> 'length' in all cases will lead 3 x 32-bit values for a FDT_PROPDATA_PHANDLE
> tag (tag + length + offset) instead of the 2 x 32-bit (tag + offset).
> 
> Back to juno.dts instead of 1960 bytes, the FDT_PROPDATA_PHANDLE will need
> 1960 * 3 / 2 = 2640 bytes (+9.7%). This leads to around +2.5% of the whole
> dtb just to have the 32-bit for length. This +2.5% can be easily avoided.
> 
> Also, I will not be surprised to see more tags in the future adding some more
> metadata information and so increasing dtb sizes.
> 
> Quite often you have mentioned memory constraints system where libfdt should
> be as small as possible. On those system, the dtb itself is embedded in the
> binary close to libfdt. The size of dtb should be taken into account.

Yeah, those proportions are high enough that I think it's worth it.

> If the SAFE_SKIP bit is removed, I even plan to use this now free bit in the
> length encoding part:
>   0b000: No data
>   0b001: 1 fdt32
>   0b010: 2 fdt32
>   ...
>   0b110: 6 fdt32
>   0b111: On additional fdt32 to encode the length of data.
> 
> IHMO, length encoding bits in tag value definition should be kept and used
> for all tags where the length is fixed and can be encoded using
> these bits.

Well, I'm convinced we want some sort of compact encoding of the
length, but I think we can do better than the current proposal.  It
seems implausible to me that we'll need 2^29 different metadata tags,
so I think we can spend some more of the tag bits on the length.  How about:

   0x80000000		structured tag bit
   0x7fff0000		tag type
   0x0000ffff		tag length

So we have up to 2^15 (32k) different structured tags each with a
length of [0..65534] bytes (length==65535 reserved for those that need
a full 32-bit length word).

I believe that will avoid the extra length word for everything you
have currently drafted.

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