From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH V2 01/12] Create efi-shared.[ch], and move string functions Date: Thu, 07 Aug 2014 07:17:44 +0100 Message-ID: <53E336280200007800029FCC@mail.emea.novell.com> References: <1405989815-25236-1-git-send-email-roy.franz@linaro.org> <1405989815-25236-2-git-send-email-roy.franz@linaro.org> <53CFFF74020000780002540C@mail.emea.novell.com> <1406562064.17854.1.camel@kazak.uk.xensource.com> <53D68DD70200007800026C29@mail.emea.novell.com> <1406562976.17854.8.camel@kazak.uk.xensource.com> <53D68FBB0200007800026C45@mail.emea.novell.com> <1406563445.17854.14.camel@kazak.uk.xensource.com> <53D6920B0200007800026CB0@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Roy Franz Cc: keir , Ian Campbell , tim , xen-devel , Stefano Stabellini , linaro-uefi , Fu Wei List-Id: xen-devel@lists.xenproject.org >>> On 07.08.14 at 01:55, wrote: > On Mon, Jul 28, 2014 at 9:10 AM, Jan Beulich wrote: >>>>> On 28.07.14 at 18:04, wrote: >>> Rather than arch .c files including common .c (or .inc) files how about >>> making xen/arch/*/efi/Makefile link xen/commmon/efi/built-in.o into it's >>> own built-in.o instead of having xen/common/Makefile do it like would >>> normally happen? >> >> That's an option. But I agree the inclusion of .c in another .c isn't >> really nice; I would therefore anyway favor a (set of) arch header >> file(s) providing everything the common code can't do on its own. > > I think I have pretty good handle addressing all of the feedback with > the exception of this build issue. Jan - I don't understand your above > suggestion. The process would be - move all files containing pieces you want to re-use from arch/x86/efi/ to common/efi/, with no other changes than to make them build again - possibly in a step by step manner, replace any code portions not suitable for non-x86 by inline functions placed in said header - add ARM variants of anything moved to the x86-specific helper header (and possible empty x86 variants of stuff ARM needs that x86 doesn't) > Another way to handle this would be for the x86 EFI code to copy > (or link) the efi-shared.c file locally for building, where it's use would > be controlled by the PE/COFF toolchain autodetection. It seems that > some kind of games will need to be played to have the autodetection > cooperate with building shared code. Yes, that would be an option too, with the linking done in a prerequisite build step. While I generally dislike this model, I do see its simplicity being a possible advantage here. Jan