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

[Palmer Dabbelt]

On Tue, 06 May 2025 13:30:02 PDT (-0700), enh@google.com wrote:
> 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.)

There'd also be a bunch of new ABI there, so presumably we're OK from a 
compatibility standpoint?

>> 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/

No, that isn't a thing on RISC-V.  It's different than how x86 works: 
rv32 is a different ISA than rv64, not a subset like i386/amd64.  So you 
can't just run rv32 code in an rv64 environment, you need support.  That 
all got shot down upstream recently.

So if users want 32-bit userspace, they just get a 32-bit kernel too.

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