From: Thavatchai Makphaibulcboke <thavatchai.makpahibulchoke@hp.com>
To: Lasse Collin <lasse.collin@tukaani.org>
Cc: "lethal@linux-sh.org" <lethal@linux-sh.org>,
"hpa@zytor.com" <hpa@zytor.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"x86@kernel.org" <x86@kernel.org>,
"kaloz@openwrt.org" <kaloz@openwrt.org>,
"matt.fleming@intel.com" <matt.fleming@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>,
"linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"schwidefsky@de.ibm.com" <schwidefsky@de.ibm.com>,
"heiko.carstens@de.ibm.com" <heiko.carstens@de.ibm.com>,
"linux390@de.ibm.com" <linux390@de.ibm.com>
Subject: Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions
Date: Fri, 25 May 2012 10:31:47 -0600 [thread overview]
Message-ID: <4FBFB3F3.1000606@hp.com> (raw)
In-Reply-To: <20120525113432.3beea6ed@tukaani.org>
On 05/25/2012 02:34 AM, Lasse Collin wrote:
> On 2012-05-24 T Makphaibulchoke wrote:
>> The patch cleans up the file lib/decompress_unxz.c by removing all
>> memory helper functions, e.g., memmove. By doing so, any
>> architecture's preboot environment supporting the XZ decompression
>> needs to define its own copy of any of the missing memory helper
>> functions.
>
> Is it best to copy these functions to each arch, or would it be better
> to have a shared file from which these functions could be pulled for
> multiple archs? I wasn't sure when I wrote decompress_unxz.c, which is
> why I put the extra functions there as a temporary solution.
>
Yes, I agree that having a shared file would be the best solution.
Unfortunately with the current preboot architecture and infra structure,
it would not be a trivial task. I believe defining these functions for
each arch would give a better code modularity compared to including them
in the decompressor file.
>> Adding both the missing memmove and memcmp functions, required by the
>> XZ decompressor, to the sh preboot environment.
>>
>> Adding the missing memmove function, required by XZ decompressor, to
>> the x86 preboot environment.
>
> These already have memcpy. It can save a few bytes if one reused
> memmove as memcpy when using XZ compression. I got a difference of 48
> bytes on x86_64.
>
We could do that. But according to the comment in the original
implementation, there seems to be a concern regarding its performance
speed. If you believe all archs' memcpy would give comparable
performance to the memmove. then I could do that.
> Adding memmove to string.c on x86 means that memmove is included in the
> kernel image even when memmove isn't needed. With gzip compression I
> got 128 bytes bigger image on x86_64 after adding the unneeded memmove
> to string.c.
>
> I don't know if those size increases matter in practice.
>
>> + * To support XZ-decompressed file in preboot environment, the
>
> s/XZ-decompressed/XZ-compressed/ :-)
>
For x86, I think I could move memmove to the misc.c file and put an
ifdef XZ_PREBOOT around it. This way it should not impact other
decompressor. I could also do this for s390 and sh. But if we decide
to replace memmove with memcpy this would be necessart.
Thank you very for your comment. Please let me know what you think.
I'll redo and send out a new patch. Thanks in advance.
Thanks,
Mak.
next prev parent reply other threads:[~2012-05-25 16:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-24 16:03 [PATCH] lib/decompress_unxz.c: removing all memory helper functions T Makphaibulchoke
2012-05-24 17:26 ` Joe Perches
2012-05-24 17:29 ` H. Peter Anvin
2012-05-24 17:40 ` Joe Perches
2012-05-24 17:41 ` H. Peter Anvin
2012-05-24 17:50 ` Joe Perches
2012-05-24 17:56 ` H. Peter Anvin
2012-05-25 8:34 ` Lasse Collin
2012-05-25 16:31 ` Thavatchai Makphaibulcboke [this message]
2012-05-25 17:05 ` Thavatchai Makphaibulcboke
2012-05-25 17:13 ` H. Peter Anvin
2012-05-25 19:35 ` Lasse Collin
2012-05-28 7:03 ` Jean-Christophe PLAGNIOL-VILLARD
2012-06-01 2:48 ` Thavatchai Makphaibulcboke
2012-06-01 2:54 ` Joe Perches
2012-06-01 3:38 ` H. Peter Anvin
2012-06-01 18:37 ` Thavatchai Makphaibulcboke
2012-06-01 18:46 ` H. Peter Anvin
2012-06-01 18:58 ` Thavatchai Makphaibulcboke
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=4FBFB3F3.1000606@hp.com \
--to=thavatchai.makpahibulchoke@hp.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=kaloz@openwrt.org \
--cc=lasse.collin@tukaani.org \
--cc=lethal@linux-sh.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux390@de.ibm.com \
--cc=linux@arm.linux.org.uk \
--cc=matt.fleming@intel.com \
--cc=mingo@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox