Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface

[Evan Green <evan@rivosinc.com>]

On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 14/02/24 11:31, Evan Green wrote:
> >
> > This series illustrates the use of a recently accepted Linux syscall that
> > enumerates architectural information about the RISC-V cores the system
> > is running on. In this series we expose a small wrapper function around
> > the syscall. An ifunc selector for memcpy queries it to see if unaligned
> > access is "fast" on this hardware. If it is, it selects a newly provided
> > implementation of memcpy that doesn't work hard at aligning the src and
> > destination buffers.
> >
> > For applications and libraries outside of glibc that want to use
> > __riscv_hwprobe() in ifunc selectors, this series also sends a pointer
> > to the riscv_hwprobe() function in as the second argument to ifunc
> > selectors. A new inline convenience function can help application and
> > library callers to check for validity and quickly probe a single key.
>
> I still think we should address Jessica Clarke remarks for the ifunc ABI [1].
> I recall that Florian has tried to address the ifunc ordering and that
> Jessica proposed solutions was not fully sufficient to address all the
> ifunc corner cases.
>
> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html

I haven't invested the time yet in studying the resolver to understand
how feasible Jessica's suggestion is. I was sort of hoping Florian
would chime in with an "oh yeah let's do that" or "no, it doesn't
work". I suppose I still am :)

Alternatively, patches 1-3 of this series stand on their own. If the
ifunc aspect of this is gated on me doing a bunch of research, it
might at least make sense to land the first half now, to get Linux
users easy access to the __riscv_hwprobe() syscall and vDSO.

-Evan