mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Yegor Yefremov <yegorslists@googlemail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Falco Hyfing <hyfinglists@gmail.com>,
	barebox <barebox@lists.infradead.org>
Subject: Re: [PATCH] lib: xz: add support for bcj filters
Date: Wed, 22 Feb 2017 11:10:36 +0100	[thread overview]
Message-ID: <CAGm1_ktrPpdx3_OGqHfdD2mwCaf9_d=V3y4xXJhX6NYpz5YkEA@mail.gmail.com> (raw)
In-Reply-To: <20170222100350.anjucafhspmwsa2c@pengutronix.de>

On Wed, Feb 22, 2017 at 11:03 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> On Wed, Feb 22, 2017 at 09:15:36AM +0100, Yegor Yefremov wrote:
>> On Wed, Feb 22, 2017 at 5:29 AM, Jean-Christophe PLAGNIOL-VILLARD
>> <plagnioj@jcrosoft.com> wrote:
>> >
>> >> On Feb 21, 2017, at 10:47 PM, yegorslists@googlemail.com wrote:
>> >>
>> >> From: Yegor Yefremov <yegorslists@googlemail.com>
>> >>
>> >> Add missing configuration options for various bcj filters. Without
>> >> these options the lib/xz/xz_dec_bcj.c file will be compiled, but all
>> >> filters will be disabled.
>> >>
>> >> Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
>> >> ---
>> >> lib/Kconfig | 28 ++++++++++++++++++++++++++++
>> >> 1 file changed, 28 insertions(+)
>> >>
>> >> diff --git a/lib/Kconfig b/lib/Kconfig
>> >> index f9f25bdef..83dd8e0a4 100644
>> >> --- a/lib/Kconfig
>> >> +++ b/lib/Kconfig
>> >> @@ -22,6 +22,34 @@ config XZ_DECOMPRESS
>> >>       bool "include xz uncompression support"
>> >>       select UNCOMPRESS
>> >>
>> >> +if XZ_DECOMPRESS
>> >> +
>> >> +config XZ_DEC_X86
>> >> +        bool "x86 BCJ filter decoder"
>> >> +        default y
>> > this need to be ARCH dependant
>>
>> Why? In Linux kernel it is not arch dependent, because AFAIK it
>> describes only compression particularities. This way you can extract
>> sqaushfs images on your ARM machine, that were compressed on SPARK
>> etc.
>
> So xz uses the Sparc bcj filter even when compressing ARM binaries? That
> doesn't sound very mature to me.

This is just an xz command line option. So it is completely in the
user responsibility.

A passage from man page:

" A BCJ filter converts relative addresses in the machine code to
their absolute counterparts.  This doesn't change the size of the
data, but it increases redundancy, which can help LZMA2 to produce
0-15 %  smaller .xz file.  The BCJ filters are always reversible, so
using a BCJ filter for wrong type of data doesn't cause any data loss,
although it may make the compression ratio slightly worse."

> It is quite surprising to me that I have to enable XZ_DEC_X86 in barebox
> since this is the architecture the xz binary was most likely compressed
> on. Also it's surprising that XZ_DEC_X86 won't bring us any gain since
> the xz binary will most likely contain ARM instructions on a ARM build,
> except that without XZ_DEC_X86 enabled it will not work.
>
> Then in bcj_apply() we have:
>
> #ifdef XZ_DEC_X86
>         case BCJ_X86:
>                 filtered = bcj_x86(s, buf, size);
>                 break;
> #endif
>
> ...
>
>         default:
>                 /* Never reached but silence compiler warnings. */
>                 filtered = 0;
>
> This is simply not true when any of the ifdefs is not true.
>
> I think we should enable all the XZ_DEC_* options but without making them
> visible since if someone ever stumbles upon these options and changes them
> he will most likely do it wrong.

OK. I'll send v2.

Yegor

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2017-02-22 10:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 14:47 yegorslists
2017-02-22  4:29 ` Jean-Christophe PLAGNIOL-VILLARD
2017-02-22  8:15   ` Yegor Yefremov
2017-02-22 10:03     ` Sascha Hauer
2017-02-22 10:10       ` Yegor Yefremov [this message]
2017-02-22 10:21         ` Sascha Hauer
2017-02-22 10:35           ` Yegor Yefremov
2017-02-22 11:34             ` Sascha Hauer

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='CAGm1_ktrPpdx3_OGqHfdD2mwCaf9_d=V3y4xXJhX6NYpz5YkEA@mail.gmail.com' \
    --to=yegorslists@googlemail.com \
    --cc=barebox@lists.infradead.org \
    --cc=hyfinglists@gmail.com \
    --cc=s.hauer@pengutronix.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox