[PATCH] arm64: signal: Update sigcontext reservations table

[Dave Martin]

On Wed, Jul 31, 2024 at 05:14:46PM +0100, Mark Brown wrote:
> On Wed, Jul 31, 2024 at 05:09:36PM +0100, Dave Martin wrote:
> > On Wed, Jul 31, 2024 at 03:58:00PM +0100, Mark Brown wrote:
> 
> > > + * where vl is the non-streaming SVE vector length, as set with PR_SVE_SET_VL,
> > > + * and svl is the streaming SVE vector length, as set with PR_SME_SET_VL.
> 
> > > I'd just say VL is the vector length, that's the term the architecture
> > > uses and it says it's set with PR_SVE_SET_VL to clarify.
> 
> > It's the worst-case sigframe size that we care about here, regardless
> > of what code a signal is delivered in the middle of.  Surely that
> > depends on both vector length settings?
> 
> Sure - what I'm saying is that you should refer to the non-streaming
> vector length as just the vector length in line with the architecture
> terminology.  The architecture does refer to the streaming vector length
> as the streaming SVE vector length sometimes so I guess we can stick
> with that there.
> 
> > Can you think of a description that clarifies this?
> 
> s/non-streaming SVE vector length/vector length/

Oh, I thought you were commenting on the pair of statements making an
unnecessary distinction, rather than just commenting on the wording
for PR_SVE_SET_VL.
 
I thought that "non-streaming SVE vector length" might be less
ambiguous given that there was no SME when I originally worded this.
I have no problem with just saying "vector length" to refer to this
setting though.

You're right that mentioning PR_SVE_SET_VL should make it unambiguous
anyway.

Cheers
---Dave