From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roy Franz Subject: Re: [PATCH V5 02/15] Move x86 specific funtions/variables to arch header Date: Mon, 22 Sep 2014 19:08:20 -0700 Message-ID: References: <1411080607-32365-1-git-send-email-roy.franz@linaro.org> <1411080607-32365-3-git-send-email-roy.franz@linaro.org> <542038090200007800036F13@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <542038090200007800036F13@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: keir , Ian Campbell , tim , xen-devel , Stefano Stabellini , Fu Wei List-Id: xen-devel@lists.xenproject.org On Mon, Sep 22, 2014 at 5:54 AM, Jan Beulich wrote: >>>> On 19.09.14 at 00:49, wrote: >> --- /dev/null >> +++ b/xen/include/asm-x86/efi-boot.h >> @@ -0,0 +1,135 @@ >> +/* >> + * Architecture specific implementation for EFI boot code. This file >> + * is intended to be included by XXX _only_, and therefore can define >> + * arch specific global variables. >> + */ >> +#include >> +#include >> +#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with EFI) */ >> +#include >> +#undef __ASSEMBLY__ >> +#include >> +#include >> + >> +static struct file __initdata ucode; >> +static multiboot_info_t __initdata mbi = { >> + .flags = MBI_MODULES | MBI_LOADERNAME >> +}; >> +static module_t __initdata mb_modules[3]; >> + >> +extern char start[]; >> +extern u32 cpuid_ext_features; > > I don't think these (and other extern-s) are valid to be put here. > > Jan > Why not, and where should they go?? cpuid_ext_features is x86 architecture specific, and start[] is only used by the x86 code by the place_string() allocator. The extern declaration is in the file in which the variables are referenced. extern l4_pgentry_t *efi_l4_pgtable; maybe should be moved back to boot.c for now, but this is an x86 specific structure that is only referenced there due to the runtime code being #ifdef'ed out. Roy