On Tue, Apr 23, 2024 at 01:55:07PM +0500, Muhammad Usama Anjum wrote: > On 4/22/24 10:21 PM, Will Deacon wrote: > > Isn't this going to be difficult to maintain if we have two divergent copies > > of the same stuff? From a very quick skim, a bunch of the signals stuff is > > idential to what we have on arm64... > Agreed. > Why don't we follow what x86 suite has been doing? Compile tests for both > arm and arm64, and add conditionals in the tests based on architecture. > If someone has objection that the suite name is arm64, just rename it to > arm which would be a generic name. Given that we haven't done that for any other arm/arm64 stuff I suspect that specific approach would lead to some combination of confusion and people just plain missing the fact that the 32 bit tests are there. It's just not the idiom that's been used for handling things elsewhere so it feels like asking for people to make mistakes. With the signal tests (which seem like the only bit that's really shared here) it's mostly just some of the library code that we want to duplicate, the actual test set for 32 bit will be different. What some of the other testsuites do to pull in other tests as libraries is to just reference the source files (KVM does this with rseq IIRC). We could do that here and try to refactor the framework code for the signal tests so that it can be built for both 64 and 32 bit, then have the 32 bit Makefile pull in the shared code from the 64 bit directory. I'm not sure if it's worth the effort or not - there is some obvious duplication but a good chunk of the arm64 code is feature detection and handling of the extensible signal context neither of which apply for 32 bit. If we are pulling stuff out it might even make sense to have something that other non-arm architectures can use since I'm not sure how much of the framework code that can be shared is even arm specific.
Attachment:
signature.asc
Description: PGP signature
