From: "Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>
To: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH][UPDATED] support for xz compression format
Date: Tue, 16 Feb 2010 23:18:53 +0100 [thread overview]
Message-ID: <4B7B19CD.5030004@gmail.com> (raw)
In-Reply-To: <201002162304.20138.szymon@janc.net.pl>
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
Szymon Janc wrote:
> Dnia wtorek 16 luty 2010 o 22:11:50 richardvoigt@gmail.com 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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]
prev parent reply other threads:[~2010-02-16 22:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-04 21:01 [PATCH][UPDATED] support for xz compression format Szymon Janc
2010-02-16 13:12 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-02-16 13:27 ` Szymon Janc
2010-02-16 13:44 ` Vladimir 'φ-coder/phcoder' Serbinenko
2010-02-16 18:58 ` Szymon Janc
2010-02-16 21:11 ` richardvoigt
2010-02-16 21:28 ` Seth Goldberg
2010-02-16 21:46 ` richardvoigt
2010-02-16 22:04 ` Szymon Janc
2010-02-16 22:18 ` Vladimir 'φ-coder/phcoder' Serbinenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B7B19CD.5030004@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.