Joerg Sonnenberger <jo...@bec.de> writes: > On Sat, Dec 22, 2018 at 09:27:22PM +0000, 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
