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

[Florian Weimer]

>> > 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?  With 32-bit userspace
running on a 64-bit kernel?  Then those interfaces are not necessarily
equivalent.  The other cpumask system calls (sched_getaffinity etc.)
are a bit peculiar in this regard.