[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9e7157d4-bb3e-4793-ac0d-05cf67ff98d1@sirena.org.uk>
Date: Tue, 25 Jun 2024 16:42:44 +0100
From: Mark Brown <broonie@...nel.org>
To: Dev Jain <dev.jain@....com>
Cc: shuah@...nel.org, linux-arm-kernel@...ts.infradead.org,
linux-kselftest@...r.kernel.org, Catalin.Marinas@....com,
will@...nel.org, ryan.roberts@....com, rob.herring@....com,
mark.rutland@....com, linux@...linux.org.uk, suzuki.poulose@....com,
Anshuman.Khandual@....com, aneesh.kumar@...nel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/9] selftests: arm, arm64: Use ifdeffery to pull
signal infrastructure
On Tue, Jun 25, 2024 at 05:54:02PM +0530, Dev Jain wrote:
> Use ifdeffery to guard code chunks meant specifically for arm64, in
> preparation for putting signal tests in selftests/arm.
I've got to say I don't love this but I'm not sure how much better we
could do if we want to share the code. Though one thing that did jump
out at me was:
> +/* Not used by selftests/arm */
> +#ifdef __aarch64__
> #define __stringify_1(x...) #x
> #define __stringify(x...) __stringify_1(x)
>
> @@ -43,6 +45,7 @@ enum {
> #define FEAT_SME (1UL << FSME_BIT)
> #define FEAT_SME_FA64 (1UL << FSME_FA64_BIT)
> #define FEAT_SME2 (1UL << FSME2_BIT)
> +#endif
There's a lot of ifdefs around feature handling. Could we reduce the
ifdeffery by instead of removing all the code just removing the
definitions of the features and the bit that initialises them based on
the hwcaps? In general a stubbing out approach like that tends to be
cleaner and less fragile.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists