Joerg Sonnenberger writes:
> On Sat, Dec 22, 2018 at 09:27:22PM +, Cherry G. Mathew wrote:
>> Module Name: src
>> Committed By:cherry
>> Date:Sat Dec 22 21:27:22 UTC 2018
>>
>> Modified Files:
>> src/sys/arch/amd64/amd64: cpufunc.S
>> src/sys/arch/i386/i386: cpufunc.S i386func.S
>> src/sys/arch/xen/x86: xenfunc.c
>>
>> Log Message:
>> Introduce a weak alias method of exporting different implementations
>> of the same API.
>
> Why? As in: what's the advantage of making them weak.
>
I'd posted separately before this commit explaining the rationale.
Here's the scenario above:
let's take lcr3(). On native this is a ring3 operation, implemented in
assembler. On xen, this is a PV call. Currently there's no need to have
both implementations in a single binary, since PV and native binaries
are distinct. With PVHVM, we have a situation where at boot time, the
native version is required, and after XEN is detected, we can use the
XEN version of the call. I've taken the approach of naming the
individual functions distinctly, eg: i386_lcr3(), or xen_lcr3(), while
and exporting them weakly as the consumed version, ie; lcr3().
What happens is that when the individual binary is compiled, the
appropriate weakly exported symbol takes over, and things work as
expected. When the combined binary for PVHVM is required, we write a
strongly exported "switch" function, called lcr3() (I haven't committed
this yet) which overrides both the weak symbols. It can then do the
runtime calls by calling into the appropriate i386_lcr3() or xen_lcr3(),
depending on the mode in which it is running.
In the specific case above however, I realised that most of the
functions I converted are not appropriate for use in PVHVM as the native
versions are likely to be more efficient. I may roll them back once
things stabilise.
I hope this was a useful explanation.
--
~cherry
