On Fri, Dec 28, 2018 at 08:09:41AM +0100, Maxime Villard wrote:
> Resending to the correct list:
>
> Le 27/12/2018 à 23:34, Christoph Badura a écrit :
> > Doesn't that trigger a kernel version bump?
>
> It doesn't change the ABI, so no.
>
> > And shouldn't changes like this be documented in
Introduce a weak alias method of exporting different implementations
of the same API.
Please revert or fix this change. 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
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,
> 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
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
Does anything simpler than GCC crash?
BTW while looking at it I noticed GCC has
gcc/arch/vax/auto-host.h
1389:#define HAVE_INITFINI_ARRAY_SUPPORT 0
So we might wanna re-run mknative at the end.
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, 3:49pm, m...@netbsd.org (m...@netbsd.org) wrote:
-- Subject: Re: CVS commit: src/libexec/ld.elf_so
| Does anything simpler than GCC crash?
|
| BTW while looking at it I noticed GCC has
| gcc/arch/vax/auto-host.h
| 1389:#define HAVE_INITFINI_ARRAY_SUPPORT 0
|
| So we might wanna
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
Resending to the correct list:
Le 27/12/2018 à 23:34, Christoph Badura a écrit :
Doesn't that trigger a kernel version bump?
It doesn't change the ABI, so no.
And shouldn't changes like this be documented in src/CHANGES?
It's a small cleanup, I don't think such changes deserve an entry
in
Hi,
On 2018/12/28 3:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Thu Dec 27 18:58:14 UTC 2018
Modified Files:
src/libexec/ld.elf_so: Makefile
src/libexec/ld.elf_so/arch/aarch64: Makefile.inc
src/libexec/ld.elf_so/arch/arm:
> 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 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
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 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 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
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 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
Thanks! GCC on m68k gets working again.
rin
On 2018/12/29 3:17, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Fri Dec 28 18:17:11 UTC 2018
Modified Files:
src/lib/csu/arch/aarch64: Makefile.inc
src/lib/csu/arch/arm: Makefile.inc
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
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
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.
>
>
25 matches
Mail list logo
