Re: [PATCH][UPDATED] support for xz compression format

[Vladimir 'φ-coder/phcoder' Serbinenko]

Szymon Janc wrote:
> Dnia wtorek 16 luty 2010 o 22:11:50 address@hidden napisał(a):
>
>   
>> Since gzip format allows decompression in pipeline mode, it's a
>> virtual certainty that nothing from the footer is required for
>> processing.
>>
>> And of course this is true of the xz format as well.  I quote from the
>> documentation:
>>     
>
> The only reason for checking footer is to get uncompressed data size to keep 
> grub_file_read() happy.
>
> Possible sollutions to avoid this:
> - add size field in stream header and break compatibility with upstream 
> xz/gz, 
> will require forking upstream compression tools or create special tool for 
> crafting upstream created files
>   
> - increase size while consuming blocks (possible with xz, don't know if with 
> gz), this leaves possibility to get grub_file_read() unhappy
>
> - try to guess uncompressed data size based on compressed size
>
>   
Solution number 4: make grub_file_read less exigent. If brainRAM serves
well file size is used only for offset checking and grub_file_size. In
first case offset checking can be effectivily disabled by setting size
to 0xffffffffffffffff. Main use of grub_file_size is to allocate a
buffer to load whole file at once. For these cases we may want to make a
grub_file_malloc_read which would arbitrate between allocation
strategies e.g. if fs->load_malloc is NULL use standard allocate/read,
otherwise call load_malloc. It is possible that some other code uses
grub_file_size (or file->size which is much uglier) in a slightly
different way but I think this solution should cover most if not all cases.
Specialised loaders may use guestimated compressed ratio, when it's
overflown (unlikely if estimation method is good), save overflow
separately by blocks and concatenate when done


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

signature.asc
Description: OpenPGP digital signature