From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NhVl3-0004FO-Ut for mharc-grub-devel@gnu.org; Tue, 16 Feb 2010 17:19:06 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NhVl1-0004Bq-RY for grub-devel@gnu.org; Tue, 16 Feb 2010 17:19:03 -0500 Received: from [140.186.70.92] (port=36029 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NhVl0-00049W-Nj for grub-devel@gnu.org; Tue, 16 Feb 2010 17:19:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NhVl0-0006rr-8c for grub-devel@gnu.org; Tue, 16 Feb 2010 17:19:02 -0500 Received: from mail-fx0-f215.google.com ([209.85.220.215]:52067) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NhVl0-0006rf-3x for grub-devel@gnu.org; Tue, 16 Feb 2010 17:19:02 -0500 Received: by fxm7 with SMTP id 7so6931245fxm.8 for ; Tue, 16 Feb 2010 14:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=ef74ydob6KzX4rLZJWW3A1pQFjMfpsMfQ/5T+i5G748=; b=iQ2qMkI0OhJze9VvGAgvYPsXAS7CHFO9XFqoeaxJyBGrsjxE3KhVaaiJyuU2LZbJ6Q W5QF6XyRgIX38xHIyI4+XDaEJ+TJ8tA9S3zMVwmIOcync69XdPQuR2Ko6je1H9LvPmW9 sB/iTpcTWlwr/kVhO7RkLlh5aB2nJm5rXbM98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=inlJ7HzjefmxZmdOM2nkbqPdiczkwOWPZWcx29sMX3bfTAyWgtnaJjXCrnU3dHwg0Q +eMajX4G2o18eNkdLIUizFzFEkWocJ0QLDiI7oSgY2oQS5jVpLCxLEK99QemrLIWamvs O0KfJtOCrFMepcOUr4oJiWJexg11hOmgVlRtM= Received: by 10.87.47.3 with SMTP id z3mr151955fgj.70.1266358741279; Tue, 16 Feb 2010 14:19:01 -0800 (PST) Received: from debian.bg45.phnet ([81.62.36.155]) by mx.google.com with ESMTPS id 12sm12841791fgg.12.2010.02.16.14.19.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 14:19:00 -0800 (PST) Message-ID: <4B7B19CD.5030004@gmail.com> Date: Tue, 16 Feb 2010 23:18:53 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <201002042201.17127.szymon@janc.net.pl> <201002161958.09505.szymon@janc.net.pl> <2e59e6971002161311r2a9b1f6fn9b910f52d61f42c@mail.gmail.com> <201002162304.20138.szymon@janc.net.pl> In-Reply-To: <201002162304.20138.szymon@janc.net.pl> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigAEA603B971E210796F37287D" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [PATCH][UPDATED] support for xz compression format X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 22:19:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAEA603B971E210796F37287D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Szymon Janc wrote: > Dnia wtorek 16 luty 2010 o 22:11:50 richardvoigt@gmail.com napisa=C5=82= (a): > > =20 >> 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: >> =20 > > The only reason for checking footer is to get uncompressed data size to= keep=20 > grub_file_read() happy. > > Possible sollutions to avoid this: > - add size field in stream header and break compatibility with upstream= xz/gz,=20 > will require forking upstream compression tools or create special tool = for=20 > crafting upstream created files > =20 > - increase size while consuming blocks (possible with xz, don't know if= with=20 > gz), this leaves possibility to get grub_file_read() unhappy > > - try to guess uncompressed data size based on compressed size > > =20 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 case= s. 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 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigAEA603B971E210796F37287D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkt7GdMACgkQNak7dOguQgl0VQD/firgxqmVE0ijx/jDVukKF0lq c3mC+WLEqQnmvPu9Q04BAK1N/ftmVK3l5lvETrWBPLzOQUi8WOXIo4ypwY2M32Dy =sZtp -----END PGP SIGNATURE----- --------------enigAEA603B971E210796F37287D--