> On Dec 28, 2018, at 10:14 AM, Mathew, Cherry G. wrote:
>
> ic, this probably explains why it's used sparingly so far. Thanks for the
> explanation. I'll try to educate myself on this wrt enabling this for modload.
We use weak symbols all over the place in user space. It's just that the
On Sat, Dec 29, 2018 at 01:41:08AM +0530, Mathew, Cherry G. wrote:
> Hotpatching will be ugly because we need both versions - for eg:
> xen_intr_register_xname() aliases to intr_register_xname() in DomU and
> Dom0 but we need both in the case of PVHVM.
I don't understand why you need two
Le 29/12/2018 à 08:40, Cherry G.Mathew a écrit :
Maxime Villard writes:
Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
Maxime Villard writes:
Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard writes:
Introduce a weak alias method of exporting different implementations
of
Maxime Villard writes:
> Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
>> Maxime Villard writes:
>>> Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard writes:
>> Introduce a weak alias method of exporting different implementations
>> of the same API.
>
>
John Nemeth writes:
> On Dec 28, 11:52pm, "Mathew, Cherry G." wrote:
> } On December 28, 2018 9:54:11 PM GMT+05:30, John Nemeth
> wrote:
> } >On Dec 28, 7:36pm, "Cherry G.Mathew" wrote:
> } >} Maxime Villard writes:
> } >} > Le 28/12/2018 �� 14:57, Cherry G.Mathew a ��crit :
> } >} >> Maxime
> On Dec 28, 2018, at 6:44 PM, John Nemeth wrote:
>
> However, having said that, I suspect that your work with PVHVM
> (and presumably PVH after that) will make the idea of having seperate
> modules for Xen obsolete. I.e. it appears to me that we're headed
> to a world where a single
> On Dec 28, 2018, at 1:32 PM, Paul Goyette wrote:
>
> The in-kernel linker doesn't deal with weak symbols at all. It would
> need a lot of thought to get it right. For example, if module A
> (containing a weak reference) gets loaded, its weak references don't
> resolve. Then module B gets
On Fri, 28 Dec 2018, Cherry G.Mathew wrote:
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.
The
Hotpatching will be ugly because we need both versions - for eg:
xen_intr_register_xname() aliases to intr_register_xname() in DomU and Dom0 but
we need both in the case of PVHVM.
So the other option is function pointers - but this will require re-prototyping
all function names that PVHVM
On Fri, Dec 28, 2018 at 07:36:12PM +0530, Cherry G.Mathew wrote:
> > 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
On December 28, 2018 9:54:11 PM GMT+05:30, John Nemeth
wrote:
>On Dec 28, 7:36pm, "Cherry G.Mathew" wrote:
>} Maxime Villard writes:
>} > Le 28/12/2018 �� 14:57, Cherry G.Mathew a ��crit :
>} >> Maxime Villard writes:
>} Introduce a weak alias method of exporting different
On December 28, 2018 11:28:01 PM GMT+05:30, Jason Thorpe wrote:
>
>> On Dec 28, 2018, at 9:50 AM, Mathew, Cherry G. wrote:
>>
>> That seems like a dependency burden on people developing new
>features. I can't tell if modload is the only way to get NVMM to run.
>If it is, then ok. If not, then
On December 28, 2018 9:54:11 PM GMT+05:30, John Nemeth
wrote:
>On Dec 28, 7:36pm, "Cherry G.Mathew" wrote:
>} Maxime Villard writes:
>} > Le 28/12/2018 �� 14:57, Cherry G.Mathew a ��crit :
>} >> Maxime Villard writes:
>} Introduce a weak alias method of exporting different
On December 28, 2018 8:40:11 PM GMT+05:30, Jason Thorpe wrote:
>
>> On Dec 28, 2018, at 6:06 AM, Cherry G.Mathew wrote:
>>
>> 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
On December 28, 2018 7:58:10 PM GMT+05:30, Maxime Villard
wrote:
>Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
>> Maxime Villard writes:
>>> Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard writes:
>> Introduce a weak alias method of exporting different
Cherry G. Mathew writes:
[...]
> I think I'll revert these for now,
PS: I'm in transit and probably not the best time to do this - if you
feel like it's urgent enough, please feel free to rollback. I'll fix
breakage on my end once the dust settles. I'll be in a commitable place
in ~48hrs.
> On Dec 28, 2018, at 6:06 AM, Cherry G.Mathew wrote:
>
> 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.
...but as the person who committed
Maxime Villard writes:
> Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
>> Maxime Villard 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
Le 28/12/2018 à 15:06, Cherry G.Mathew a écrit :
Maxime Villard writes:
Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard 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
Le 28/12/2018 à 14:57, Cherry G.Mathew a écrit :
Maxime Villard 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
Maxime Villard 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 ?
> The kernel modules that use these functions can't be modloaded
> anymore,
21 matches
Mail list logo
