| Message ID | 20240422070717.2194201-1-dev.jain@arm.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | A new selftests/ directory for arm compatibility testing | expand |
On Mon, Apr 22, 2024 at 12:37:13PM +0530, Dev Jain wrote: > This series introduces the selftests/arm directory, which tests 32 and 64-bit > kernel compatibility with 32-bit ELFs running on the Aarch platform. > The need for this bucket of tests is that 32 bit applications built on legacy > ARM architecture must not break on the new Aarch64 platforms and the 64-bit > kernel. The kernel must emulate the data structures, system calls and the > registers according to Aarch32, when running a 32-bit process; this directory > fills that testing requirement. > > One may find similarity between this directory and selftests/arm64; it is > advisable to refer to that since a lot has been copied from there itself. 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... Will
On 4/22/24 10:21 PM, Will Deacon wrote: > On Mon, Apr 22, 2024 at 12:37:13PM +0530, Dev Jain wrote: >> This series introduces the selftests/arm directory, which tests 32 and 64-bit >> kernel compatibility with 32-bit ELFs running on the Aarch platform. >> The need for this bucket of tests is that 32 bit applications built on legacy >> ARM architecture must not break on the new Aarch64 platforms and the 64-bit >> kernel. The kernel must emulate the data structures, system calls and the >> registers according to Aarch32, when running a 32-bit process; this directory >> fills that testing requirement. >> >> One may find similarity between this directory and selftests/arm64; it is >> advisable to refer to that since a lot has been copied from there itself. > > 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. > > Will >
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.