[PATCH 16/25] binman: Avoid reporting image-pos with compression

[Alper Nebi Yasak]

On 30/10/2020 21:15, Simon Glass wrote:
> Hi Alper,
> 
> On Mon, 26 Oct 2020 at 17:20, Alper Nebi Yasak <alpernebiyasak at gmail.com> wrote:
>> What I meant is using pairs of <position-of-compressed-archive>,
>> <position-in-uncompressed-data> to avoid losing position information of
>> compressed entries, but honestly I'm not sure if any of this will be
>> necessary. I think the single use would be to avoid parsing uncompressed
>> data containing multiple entries to identify what is where.
> 
> For the CBFS case there isn't anything needed I think.
> 
> We already have an offset field which tells you where something is in
> the compressed data. For the case where a compressed section has just
> other entries in it, the offset is enough.

That completely slipped my mind. I haven't got a good grasp on all of
this yet and it shows :)

So it's possible to just traverse down the tree, keep adding offsets,
decompress any encountered compressed entry, then keep adding offsets
onto where it's decompressed, and so on.

> For the case where the compressed section has other uncompressed
> sections, we need to add together the offsets (uncompressed section +
> its entry) to get to the compressed location. It certainly has some
> benefits.
> 
> But I wonder if instead we should have a properly like comp-pos that
> tells you the absolute offset within the compressed section? I'm not a
> big fan of making image-pos a multi-cell value.

Then, image-pos is by definition the sum of offsets from the topmost
parent (image) downto the entry? If so, that comp-pos would be the same
thing but from the closest compressed parent (or simply only support one
layer of compression).

I can't think of anything specific that would need this anyway, but I
guess one compression should be enough for most if not all cases.