[PATCH v2 2/7] arm64/fpsimd: Track the saved FPSIMD state type separately to TIF_SVE

[Mark Brown]

On Wed, Jul 20, 2022 at 10:40:03AM +0100, Marc Zyngier wrote:
> Mark Brown <broonie at kernel.org> wrote:

> > Yes, someone might forget to update the state type but my experience
> > with this code is that it's a lot easier to spot "this is writing new
> > state, did it update the state type?" than "this is writing new state,
> > did it call the helper that implicitly updates the state type or the
> > other one?".

> My experience in maintaining the KVM code is that the least state
> leaks outside of this sort of helpers, the least problematic they
> are. I'd rather have multiple helpers that have different *documented*
> behaviours than expecting the random hacker to know (or in this case,
> *guess*) when or not to add some extra state-twiddling. It also makes
> the code far more readable because it is self-contained.

> If this series is supposed to help making things more maintainable,
> then this is one way to do it.

There's nothing self contained going on, and based on what the users are
doing it isn't at all obvious to me that taking a copy of the data in
another format should be part of the same operation as deciding which
format should be the live data.  I'm all for helpers but between that
and the direct awareness the users already need to have of what's going
on I'm just not seeing that a combined convert and make active operation
is jumping out as something that should be a helper.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220720/9bc5d5b5/attachment.sig>