--- - branch: MAIN date: Sat Dec 22 21:27:22 UTC 2018 files: - new: '1.34' old: '1.33' path: src/sys/arch/amd64/amd64/cpufunc.S pathrev: src/sys/arch/amd64/amd64/cpufunc.S@1.34 type: modified - new: '1.26' old: '1.25' path: src/sys/arch/i386/i386/cpufunc.S pathrev: src/sys/arch/i386/i386/cpufunc.S@1.26 type: modified - new: '1.19' old: '1.18' path: src/sys/arch/i386/i386/i386func.S pathrev: src/sys/arch/i386/i386/i386func.S@1.19 type: modified - new: '1.23' old: '1.22' path: src/sys/arch/xen/x86/xenfunc.c pathrev: src/sys/arch/xen/x86/xenfunc.c@1.23 type: modified id: 20181222T212722Z.1b0ff27a57bdc1a6cad0aadf91ad2a96ec0884a0 log: | Introduce a weak alias method of exporting different implementations of the same API. For eg: the amd64 native implementation of invlpg() now becomes amd64_invlpg() with a weak symbol export of invlpg(), while the XEN implementation becomes xen_invlpg(), also weakly exported as invlpg() Note that linking in both together without having an override function named invlpg() would be a mistake, as we have limited control over which of the two options would emerge as the finally exported invlpg() resulting in a potential situation where the wrong function is finally exported. This change avoids this situation. We should however include an override function invlpg() in that case, such that it is able to then pass on the call to the appropriate backing function (amd64_invlpg() in the case of native, and xen_invlpg() in the case of under XEN virtualisation) at runtime. This change does not introduce such a function and therefore does not alter builds to include native as well as XEN implementations in the same binary. This will be done later, with the introduction of XEN PVHVM mode, where precisely such a runtime switch is required. There are no operational changes introduced by this change. module: src subject: 'CVS commit: src/sys/arch' unixtime: '1545514042' user: cherry