On 15 Feb 2023, at 21:14, Evan Green <evan@xxxxxxxxxxxx> wrote:
>
> On Wed, Feb 15, 2023 at 1:57 AM Arnd Bergmann <arnd@xxxxxxxx> wrote:
>>
>> On Mon, Feb 6, 2023, at 21:14, Evan Green wrote:
>>> We don't have enough space for these all in ELF_HWCAP{,2} and there's no
>>> system call that quite does this, so let's just provide an arch-specific
>>> one to probe for hardware capabilities. This currently just provides
>>> m{arch,imp,vendor}id, but with the key-value pairs we can pass more in
>>> the future.
>>>
>>> Co-developed-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
>>> Signed-off-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>
>>> Signed-off-by: Evan Green <evan@xxxxxxxxxxxx>
>>
>> I'm not sure I understand the problem with
>> AT_HWCAP. While the bits in AT_HWCAP and AT_HWCAP2
>> are limited, I don't see us running out of new
>> AT_* words to use for additional bits. Presumably
>> the kernel would already have to know about the
>> name of each supported HW feature and could assign
>> a unique bit number to them.
>
> Palmer can probably speak to this with more authority, but my
> understanding about the motivation for an approach like this goes
> something like:
> * With the nature of RISC-V, we expect a lot of these types of bits
> and bobs, many more than we've seen with the likes of x86 and ARM.
We’re already at (I think) 51 standard user-level extensions that LLVM
knows about.
> * We also expect in some cases these values to be inconsistent across CPUs.
That’s also true of some Arm SoCs.
> * While we could copy all that data into the aux vector every time,
> it starts to look like a lot of data, not all programs care about all
> of it, and a lot of it is static, making all the copying wasteful.
Bitvectors are pretty cheap, this is negligible.
> * Another option that would solve most of this would be to point to a
> vDSO data area from the aux vector. This solves the copy complaints,
> but makes that vDSO data ABI, and requires it all to be known up
> front.
That doesn't seem like a huge deal, other than my usual point of
needing a standardised portable cross-platform API for this, so that
shouldn’t be “the” generic interface programmed against by applications.
> * So, a syscall with a vDSO function in front of it seemed like a
> good combination of speed and flexibility.
>
> You're certainly right that HWCAPn would work for what we're exposing
> today, so the question probably comes down to our relative predictions
> of how this data will grow.
The other big problem is vendor extensions.
Jess
> -Evan
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv
