On 26/10/2020 22:22, Simon Glass wrote:
> Hi Alper,
>
> On Mon, 19 Oct 2020 at 15:29, Alper Nebi Yasak <alpernebiya...@gmail.com>
> wrote:
>>
>> On 19/10/2020 05:41, Simon Glass wrote:
>>> When a section is compressed, all entries within it are grouped together
>>> into a compressed block of data. This obscures the start of each
>>> individual child entry.
>>>
>>> Avoid reporting bogus 'image-pos' properties in this case, since it is
>>> not possible to access the entry at the location provided. The entire
>>> section must be decompressed first.
>>>
>>> CBFS does not support compressing whole sections, only individual files,
>>> so needs no special handling here.
>>>
>>> Signed-off-by: Simon Glass <s...@chromium.org>
>>> ---
>>
>> Maybe instead of this, 'image-pos' could be overloaded to a list of
>> recursive relative positions within compressed archives? Something like:
>>
>> section {
>> offset = <1000>;
>> compress = "lz4";
>> /* image-pos = <1000>; */
>>
>> blob {
>> filename = "foo";
>> offset = <100>;
>> /* image-pos = <1000>, <100>; */
>> };
>> };
>>
>> cbfs {
>> offset = <2000>;
>> /* image-pos = <2000>; */
>>
>> blob {
>> filename = "bar";
>> cbfs-compress = "lz4";
>> cbfs-offset = <200>;
>> /* image-pos = <2200>, <0>; */
>> };
>>
>> blob2 {
>> filename = "baz";
>> cbfs-offset = <800>;
>> /* image-pos = <2800>; */
>> };
>> };
>>
>
> What do these values actually mean though? What would we use them for?
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.
To get to an entry in a compressed section we could get "size" bytes of
data starting from "image-pos[0]", decompress that to somewhere, then
get "uncomp-size" bytes of data starting from decompression address +
"image-pos[1]". I think it can even be extended to multiple layers of
compression (<pos-of-x>, <pos-of-y-in-d(x)>, <pos-of-z-in-d(y)>, ...).
> Note that CBFS compresses its data on a per-entry basis so the
> image-pos is actually supported.
On the compressed cbfs example, I assume the data we currently get at
image-pos = <2200> is compressed data and still needs to be decompressed
for it to be useable (technically bogus?). If so, I'd go a level deeper
by adding a <0> indicating the start of the uncompressed data is the
actual position of the entry contents.
