Re: [PATCH v6 1/4] xen: introduce SYMBOL

[Stefano Stabellini <sstabellini@kernel.org>]

On Wed, 16 Jan 2019, Jan Beulich wrote:
> >>> On 16.01.19 at 00:36, <sstabellini@kernel.org> wrote:
> > On Tue, 15 Jan 2019, Jan Beulich wrote:
> >> First of all we should explore whether the variables could also be
> >> linker generated, in particular to avoid the current symbols to be
> >> global (thus making it impossible to access them from C files in the
> >> first place).
> > 
> > That would be fantastic. I looked around, I found interesting things
> > like PROVIDE, but I don't think what you describe is possible. The
> > linker scripts only define symbols, they cannot set or define variables.
> 
> Yeah, it didn't seem very likely. Then again I think the next best
> approach would still be to use .startof. / .sizeof., just not the
> way my original patch did, but in your var.S file(s). The
> fundamental goal still being to avoid exposure of the symbols
> we don't want to be used in C altogether. (All of this provided
> we need to go this intermediate variable route in the first place,
> which I continue to be unconvinced of, despite you having
> posted a respective v8 of your series.)
> 
> >> Failing that, I don't think it matters much where these
> >> helper symbols live, and hence your choice is probably fine (I'd
> >> prefer though if, just like on Arm, the x86 file didn't live in the
> >> boot/ subdirectory; in the end it might even be possible to have
> >> some of them in xen/common/var.S).
> > 
> > OK, I'll move the x86 var.S to xen/arch/x86/x86_64. I cannot share var.S
> > because arm32 is using long instead of quad.
> 
> Excuse me, but no. This is extremely easy to abstract away - see
> x86 Linux'es _ASM_PTR.

I am happy to make this change and also work on your suggestion above
about using .startof. / .sizeof. in var.S, if we agree on this approach.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel