Re: [Xen-devel] [PATCH V5 02/15] Move x86 specific funtions/variables to arch header

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 23.09.14 at 04:08, <roy.franz@xxxxxxxxxx> wrote:
> On Mon, Sep 22, 2014 at 5:54 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:
>>>>> On 19.09.14 at 00:49, <roy.franz@xxxxxxxxxx> 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 <asm/e820.h>
>>> +#include <asm/edd.h>
>>> +#define __ASSEMBLY__ /* avoid pulling in ACPI stuff (conflicts with EFI) */
>>> +#include <asm/fixmap.h>
>>> +#undef __ASSEMBLY__
>>> +#include <asm/msr.h>
>>> +#include <asm/processor.h>
>>> +
>>> +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.
> 
> 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.

I'm sorry, I only now realized they're both currently being declared
in boot.c, so moving them here is kind of okay. Nevertheless it
would seem better to find them a more appropriate home: start[]
could likely go alongside _start[] in xen/kernel.h, and
cpuid_ext_features would seem to fit into either
asm-x86/cpufeature.h or asm-x86/processor.h.

> 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.

It's currently being declared in xen/arch/x86/efi/efi.h, and I
can't really see why this isn't sufficient.

Speaking of which - putting the new header under asm-x86/ instead
of in x86/efi/ seems bogus with the changed symlinking model too.
The header should be as private as possible. Perhaps what you put
there could even go into said efi.h (possibly inside a suitable #if)?

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel