From: Michal Marek <mmarek@suse.cz>
To: Corentin Chary <corentin.chary@gmail.com>
Cc: Paul Bolle <pebolle@tiscali.nl>,
linux-kernel@vger.kernel.org,
Dick Streefland <dick@streefland.net>,
WANG Cong <xiyou.wangcong@gmail.com>
Subject: Re: [PATCH] scripts: add extract-vmlinux
Date: Thu, 11 Aug 2011 15:33:51 +0200 [thread overview]
Message-ID: <4E43DA3F.7090709@suse.cz> (raw)
In-Reply-To: <CAHR064h8souTS7HZBk_6Kc0uRqRhJDGaB_4pFgHGJRSAF_50ig@mail.gmail.com>
On 11.8.2011 15:08, Corentin Chary wrote:
> On Thu, Aug 11, 2011 at 1:28 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
>> On Thu, 2011-08-11 at 10:53 +0200, Corentin Chary wrote:
>>> +try_decompress()
>>> +{
>>> + for pos in `tr "$1\n$2" "\n$2=" < "$img" | grep -abo "^$2"`
>>> + do
>>> + pos=${pos%%:*}
>>> + tail -c+$pos "$img" | $3 > $tmp 2> /dev/null
>>
>> Perhaps a few comments on the above lines would be nice. Without those
>> comments I must guess you're finding compressed data somewhere in the
>> input file. It also seems you're looping through the entire input file.
>> Or are (sequences of) commands like the above considered obvious?
>
> It's copied from extract-ikconfig, there was no comment in it, so I
> assumed it's obvious.
> Basically it uses brute force (tm) to find well known headers and try
> to decompress from here.
And explanation of the "tr" trick would not hurt though. It replaces the
binary magic with an ascii sequence on a new line (for older grep
versions to get it right) and tries all occurrences of that sequence, am
I right? But I wouldn't call it "obvious" :).
>>> +# That didn't work, so retry after decompression.
>>> +try_decompress '\037\213\010' xy gunzip
>>> +try_decompress '\3757zXZ\000' abcde unxz
>>> +try_decompress 'BZh' xy bunzip2
>>> +try_decompress '\135\0\0\0' xxx unlzma
>>> +try_decompress '\211\114\132' xy 'lzop -d'
>>
>> Perhaps you could first test whether these commands are available before
>> running try_decompress() with them?
>
> Same as before, if it's ok for extract-ikconfig not to check the
> command, then it's ok for me.
> If it's not, then we should patch both.
Also, if you have lzma to build a lzma-compressed kernel, then you very
likely also have unlzma.
Michal
next prev parent reply other threads:[~2011-08-11 13:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-04 13:52 [PATCH] scripts: add extract-vmlinux Corentin Chary
2011-08-10 13:27 ` Michal Marek
2011-08-11 7:21 ` Corentin Chary
2011-08-11 7:53 ` Dick Streefland
2011-08-11 8:42 ` Américo Wang
2011-08-11 8:53 ` Corentin Chary
2011-08-11 11:28 ` Paul Bolle
2011-08-11 13:08 ` Corentin Chary
2011-08-11 13:33 ` Michal Marek [this message]
2011-08-11 14:23 ` Corentin Chary
2011-08-11 15:47 ` Corentin Chary
2011-08-16 8:46 ` [PATCH v3] " Corentin Chary
2011-08-18 10:09 ` Américo Wang
2011-08-26 9:49 ` Corentin Chary
2011-08-19 6:51 ` Ian Campbell
2011-08-19 7:52 ` Corentin Chary
2011-08-31 14:16 ` Michal Marek
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=4E43DA3F.7090709@suse.cz \
--to=mmarek@suse.cz \
--cc=corentin.chary@gmail.com \
--cc=dick@streefland.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pebolle@tiscali.nl \
--cc=xiyou.wangcong@gmail.com \
/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