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

From: Roy Franz <roy.franz@linaro.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: keir <keir@xen.org>, Ian Campbell <ian.campbell@citrix.com>,
	tim <tim@xen.org>, xen-devel <xen-devel@lists.xen.org>,
	Stefano Stabellini <stefano.stabellini@citrix.com>,
	Fu Wei <fu.wei@linaro.org>
Subject: Re: [PATCH V5 02/15] Move x86 specific funtions/variables to arch header
Date: Tue, 23 Sep 2014 19:35:37 -0700	[thread overview]
Message-ID: <CAFECyb8ZKhz14=-36cwXMxc93vhZSCJzmwutkWuf3+1Bp9NbOw@mail.gmail.com> (raw)
In-Reply-To: <5421828D0200007800037982@mail.emea.novell.com>

On Tue, Sep 23, 2014 at 5:24 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 23.09.14 at 04:08, <roy.franz@linaro.org> wrote:
>> On Mon, Sep 22, 2014 at 5:54 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> On 19.09.14 at 00:49, <roy.franz@linaro.org> 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.

I moved start to xen/kernel.h, and cpuid_ext_features to asm-x86/processor.h
alongside some other externs.  cpufeature.h didn't have any externs, so putting
it with other externs seemed a better fit.
>
>> 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.

xen/arch/x86/efi/efi.h is a link to common/efi/efi.h, so it is a shared
header.  I could put it there with #ifdef, or leave it the the architecture
specific header file.

>
> 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)?

Yup, putting the efi-boot.h headers in arch/XX/efi is better, so I
have moved them.

Since the efi-boot.h is a 'special' include file - ie it defines
global variables,
I think having it directly included where it is intended is a good thing.
This would also require a lot of forward declarations for functions
and global variables referenced by this implementation header but defined
in efi-boot.c.  This is all avoided right now by including efi-boot.h
a bit lower
down.

>
> Jan
>