Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
Maxime Villard <m...@m00nbsd.net> writes:
Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard <m...@m00nbsd.net> 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 symbols
I 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.