[PATCH] riscv: Correct __riscv_hwprobe function attributes [BZ #32932]

[enh]

On Tue, May 6, 2025 at 10:40 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> >> > the kernel also has the bitmask as a `cpu_set_t*` rather than
> >> > `unsigned long*` too, which seems clearer:
> >> >
> >> > long sys_riscv_hwprobe(struct riscv_hwprobe *pairs, size_t pair_count,
> >> >                        size_t cpusetsize, cpu_set_t *cpus,
> >> >                        unsigned int flags);
> >> >
> >> > https://docs.kernel.org/arch/riscv/hwprobe.html
> >> >
> >> > should we fix that too while we're here?
> >>
> >> cpu_set_t * would be consistent with other functions that take a cpu
> >> bitmask (sched_setaffinity, sched_getaffinity, pthread_setaffinity_np,
> >> pthread_getaffinity_np, pthread_attr_setaffinity_np,
> >> pthread_attr_getaffinity_np), so it is unfortunate that it was added
> >> with unsigned long *, but wouldn't changing it be a problem for any
> >> existing code that is calling it with unsigned long *?
> >
> > yeah, but that will only get worse...
> >
> > https://github.com/pytorch/cpuinfo/blob/main/src/riscv/linux/riscv-hw.c
> > is the only caller i could find that doesn't just pass null. (and
> > amusingly it's not using <sys/hwprobe.h> for glibc [or musl, though
> > that doesn't have the header yet].)
> >
> > fweimer? any precedent for fixing an intention-obscuring function
> > declaration (so it matches the kernel)?
>
> Will there ever be a big-endian RISC-V variant?

the spec allows for such a thing. (someone's giving a talk at the
risc-v summit europe next week about adding support to qemu/gcc/etc,
but i'm not aware of anyone working on hardware.)

> With 32-bit userspace
> running on a 64-bit kernel?

afaik that's allowed, just like with x86-64. looks like alibaba might
use it? https://riscv.org/blog/2023/01/run-32-bit-applications-on-64-bit-linux-kernel-liu-zhiwei-guo-ren-t-head-division-of-alibaba-cloud/

> Then those interfaces are not necessarily
> equivalent.  The other cpumask system calls (sched_getaffinity etc.)
> are a bit peculiar in this regard.