On 30/10/2020 21:15, Simon Glass wrote:
Hi Alper,
On Mon, 26 Oct 2020 at 17:20, Alper Nebi Yasak alpernebiyasak@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.