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