Hi,
While running the nolibc tests I discovered that they build a kernel in the current directory, including overwriting the existing .config. This is rather suprising for the selftests build system - it usually wouldn't do a kernel build at all - and might be annoying for users.
KUnit deals with this by doing it's kernel build in a .kunit directory, it'd probably be good to do something similar for nolibc.
Thanks, Mark
Hi Mark,
On 2025-06-09 17:42:47+0100, Mark Brown wrote:
While running the nolibc tests I discovered that they build a kernel in the current directory, including overwriting the existing .config. This is rather suprising for the selftests build system - it usually wouldn't do a kernel build at all - and might be annoying for users.
This is not intended. I think a recent configuration change is broken [0]. The order-only dependencies don't work as I thought they would. I'll rework this.
KUnit deals with this by doing it's kernel build in a .kunit directory, it'd probably be good to do something similar for nolibc.
I assume you are using "make" directly. For a more complete kunit.py-like solution we have run-tests.sh, which does indeed use a dedicated build directory.
And maybe "soon" you get to use kunit directly to test nolibc.
[0] d7d271ec30dd ("selftests/nolibc: execute defconfig before other targets")
Thomas
On Tue, Jun 10, 2025 at 07:05:59PM +0200, Thomas Weißschuh wrote:
On 2025-06-09 17:42:47+0100, Mark Brown wrote:
KUnit deals with this by doing it's kernel build in a .kunit directory, it'd probably be good to do something similar for nolibc.
I assume you are using "make" directly. For a more complete kunit.py-like solution we have run-tests.sh, which does indeed use a dedicated build directory.
Given that the tests were in tools/testing/selftests I initially tried to run them via the selftests build infra which didn't work since they're not glued into that at all and I ran into this as part of debugging. It didn't actually occur to me to look anywhere other than the Makefile, that's how you normally invoke selftests.
Given that AFAICT the tests don't use any kselftest infrastructure or otherwise overlap with it I think it'd be better to move them to tools/testing/nolibc, that'd make it clearer that they're their own thing and avoid surprises.
On 2025-06-10 18:21:27+0100, Mark Brown wrote:
On Tue, Jun 10, 2025 at 07:05:59PM +0200, Thomas Weißschuh wrote:
On 2025-06-09 17:42:47+0100, Mark Brown wrote:
KUnit deals with this by doing it's kernel build in a .kunit directory, it'd probably be good to do something similar for nolibc.
I assume you are using "make" directly. For a more complete kunit.py-like solution we have run-tests.sh, which does indeed use a dedicated build directory.
Given that the tests were in tools/testing/selftests I initially tried to run them via the selftests build infra which didn't work since they're not glued into that at all and I ran into this as part of debugging. It didn't actually occur to me to look anywhere other than the Makefile, that's how you normally invoke selftests.
Makes sense.
Given that AFAICT the tests don't use any kselftest infrastructure or otherwise overlap with it I think it'd be better to move them to tools/testing/nolibc, that'd make it clearer that they're their own thing and avoid surprises.
Also makes sense. However I plan to make the tests compatible with kselftests as one of the next steps. The custom logic will stay, but for increased test coverage the tests should also work as regular selftests.
Thomas
On Tue, Jun 10, 2025 at 10:52:02PM +0200, Thomas Weißschuh wrote:
On 2025-06-10 18:21:27+0100, Mark Brown wrote:
Given that AFAICT the tests don't use any kselftest infrastructure or otherwise overlap with it I think it'd be better to move them to tools/testing/nolibc, that'd make it clearer that they're their own thing and avoid surprises.
Also makes sense. However I plan to make the tests compatible with kselftests as one of the next steps. The custom logic will stay, but for increased test coverage the tests should also work as regular selftests.
Ah, great - if it's going to be integrated into the kselftest runtime system then that'd help a lot.
linux-kselftest-mirror@lists.linaro.org
-
Mark Brown -
Thomas Weißschuh