[PATCH 0/2] kselftest: Support nolibc

From: Mark Brown <broonie@kernel.org>
To: Shuah Khan <shuah@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mark Brown <broonie@kernel.org>
Subject: [PATCH 0/2] kselftest: Support nolibc
Date: Thu, 06 Apr 2023 14:56:28 +0100	[thread overview]
Message-ID: <20230405-kselftest-nolibc-v1-0-63fbcd70b202@kernel.org> (raw)

At present the kselftest header can't be used with nolibc since it makes
use of vprintf() which is not available in nolibc and seems like it would
be inappropriate to implement given the minimal system requirements and
environment intended for nolibc. This has resulted in some open coded
kselftests which use nolibc to test features that are supposed to be
controlled via libc and therefore better exercised in an environment with
no libc.

Rather than continue this let's factor out the I/O routines in kselftest.h
into a separate header file and provide a nolibc implementation which only
allows simple strings to be provided rather than full printf() support.
This is limiting but a great improvement on sharing no code at all.

As an example of using this I've updated the arm64 za-fork test to use
the standard kselftest.h.

Signed-off-by: Mark Brown <broonie@kernel.org>
---
Mark Brown (2):
      kselftest: Support nolibc
      kselftest/arm64: Convert za-fork to use kselftest.h

 tools/testing/selftests/arm64/fp/Makefile  |   2 +-
 tools/testing/selftests/arm64/fp/za-fork.c |  88 +++--------------
 tools/testing/selftests/kselftest-nolibc.h |  93 ++++++++++++++++++
 tools/testing/selftests/kselftest-std.h    | 151 +++++++++++++++++++++++++++++
 tools/testing/selftests/kselftest.h        | 149 +++-------------------------
 5 files changed, 272 insertions(+), 211 deletions(-)
---
base-commit: e8d018dd0257f744ca50a729e3d042cf2ec9da65
change-id: 20230405-kselftest-nolibc-cb2ce0446d09

Best regards,
-- 
Mark Brown <broonie@kernel.org>