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. >>> 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). -- ~cherry
