From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thavatchai Makphaibulcboke Date: Fri, 01 Jun 2012 02:48:41 +0000 Subject: Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions Message-Id: <4FC82D89.1040108@hp.com> List-Id: References: <1337875436-27640-1-git-send-email-tmac@hp.com> <20120528070336.GM3377@game.jcrosoft.org> In-Reply-To: <20120528070336.GM3377@game.jcrosoft.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On 05/28/2012 01:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > can we do not duplicate those functions? > > Best Regards, > J. Thanks J for the comment. Unfortunately, there is no easy way to share files among different architectures' preboot environment. We have the choices either to have each architecture define its own copies or the decompressor defines them. I believe the former is preferable. As Lasse also pointed out, this way any specific architecture could provide an architectural dependent optimized version, if it chooses to. Thanks, Mak. From mboxrd@z Thu Jan 1 00:00:00 1970 From: thavatchai.makpahibulchoke@hp.com (Thavatchai Makphaibulcboke) Date: Thu, 31 May 2012 20:48:41 -0600 Subject: [PATCH] lib/decompress_unxz.c: removing all memory helper functions In-Reply-To: <20120528070336.GM3377@game.jcrosoft.org> References: <1337875436-27640-1-git-send-email-tmac@hp.com> <20120528070336.GM3377@game.jcrosoft.org> Message-ID: <4FC82D89.1040108@hp.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 05/28/2012 01:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > can we do not duplicate those functions? > > Best Regards, > J. Thanks J for the comment. Unfortunately, there is no easy way to share files among different architectures' preboot environment. We have the choices either to have each architecture define its own copies or the decompressor defines them. I believe the former is preferable. As Lasse also pointed out, this way any specific architecture could provide an architectural dependent optimized version, if it chooses to. Thanks, Mak. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758811Ab2FACsv (ORCPT ); Thu, 31 May 2012 22:48:51 -0400 Received: from g1t0028.austin.hp.com ([15.216.28.35]:16819 "EHLO g1t0028.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757158Ab2FACst (ORCPT ); Thu, 31 May 2012 22:48:49 -0400 Message-ID: <4FC82D89.1040108@hp.com> Date: Thu, 31 May 2012 20:48:41 -0600 From: Thavatchai Makphaibulcboke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jean-Christophe PLAGNIOL-VILLARD CC: "lethal@linux-sh.org" , "hpa@zytor.com" , "tglx@linutronix.de" , "mingo@redhat.com" , "x86@kernel.org" , "kaloz@openwrt.org" , "matt.fleming@intel.com" , "lasse.collin@tukaani.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "linux@arm.linux.org.uk" , "schwidefsky@de.ibm.com" , "heiko.carstens@de.ibm.com" , "linux390@de.ibm.com" Subject: Re: [PATCH] lib/decompress_unxz.c: removing all memory helper functions References: <1337875436-27640-1-git-send-email-tmac@hp.com> <20120528070336.GM3377@game.jcrosoft.org> In-Reply-To: <20120528070336.GM3377@game.jcrosoft.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/28/2012 01:03 AM, Jean-Christophe PLAGNIOL-VILLARD wrote: > can we do not duplicate those functions? > > Best Regards, > J. Thanks J for the comment. Unfortunately, there is no easy way to share files among different architectures' preboot environment. We have the choices either to have each architecture define its own copies or the decompressor defines them. I believe the former is preferable. As Lasse also pointed out, this way any specific architecture could provide an architectural dependent optimized version, if it chooses to. Thanks, Mak.