Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
Maxime Villard <max%m00nbsd.net@localhost> writes:Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :Maxime Villard <max%m00nbsd.net@localhost> writes:Introduce a weak alias method of exporting different implementations of the same API.Please revert or fix this change.I'm not sure what the fix is - do you have a suggestion ?either re-apply it without using weak symbols, or change the modloader to accept weak symbolsI don't like the imperative in your tone. NVMM is the user of modloader, not PVHVM. So if you feel like your usecase needs fixing, I'd say it's your problem - or don't use modules, but see below.
Wut? Yes my suggestions are either we re-apply the change without using weak symbols or we change the modloader to accept weak symbols. ?
The kernel modules that use these functions can't be modloaded anymore, because weak symbols aren't resolved. Eg, NVMM can't be modloaded anymore, because it uses rcr0 among others.I think I'll revert these for now, because PVHVM doesn't/shouldn't use them anyway, but I'd like to know how to fix this properly. modload not working due to __weak_alias() sounds like something we don't do properly in the modload path.There is a check in kobj_sym_lookup(): 926 case STB_WEAK: 927 kobj_error(ko, "weak symbols not supported"); 928 return EINVAL; To resolve correctly I guess we need to take the strongest of the duplicated symbols.I'll look into this unless someone else beats me to it - but for now I'm ok for the specific change that breaks things for NVMM to be rolled back. (Please see other email about timeframe).
That's fine, I can hard-code the check on my side for now, to make it load.