Re: [PATCH v1] Documentation: riscv: update Vector discovery for userspace

["Rémi Denis-Courmont" <remi@remlab.net>]

Hi,

Late to the party but...

> Make it explicit that users may use both HWCAP and
> PR_RISCV_V_GET_CONTROL for checking the availability of Vector
> extensions.

No? Some user-space checks HWCAP. Some check `hwprobe()` in line with 
Documentation/arch/riscv/hwprobe.rst in the same directory. Some check 
hwprobe() and fallback to HWCAP.

It's a few years too late to disallow using __riscv_hwprove() for this 
purpose.

> This addresses the ABI usage concern[1] arised from the user
> space community in supporting Vector sub-exts and multiversioning.

That looks to me that it only muddles the situation more rather than clarify 
it by recommending yet another way to detect Vectors that does not match what 
running code actually does.

If it were up to me, I would just deprecate the prctl() RVV controls. Their 
original intent appears to have been to allow running legacy non-vector code 
that would hypothetically not accomodate larger machine contexts in signal 
handling. However, given that Vectors are enabled by default, backward 
compatibility in that hypothetical scenario never actually existed. So it 
seems like it was merged as some kind of bad compromise / commitee design.

Alternatively, clarify that the RVV prctl()'s are only meant for, well, 
running legacy code that can't accomodate vector registers, and MUST NOT be 
used otherwise as it is known to break apps and libraries with runtime feature 
detection.

Or, but that's going to be controversial, and arguably also an ABI break, make 
hwprobe() account for the vector state of the process.

Br,

-- 
德尼-库尔蒙‧雷米
https://www.remlab.net/




_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv