| Message ID | 20230405-kselftest-nolibc-v1-0-63fbcd70b202@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | kselftest: Support nolibc | expand |
Hi Mark, On Thu, Apr 06, 2023 at 02:56:28PM +0100, Mark Brown wrote: > 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. In fact we already have vfprintf(), and printf() is based on it, so wouldn't it just be a matter of adding vprintf() that calls vfprintf() for your case ? Maybe just something like this : static int vprintf(const char *fmt, va_list args) { return vfprintf(stdout, fmt, args); } It's possible I'm missing something, but it's also possible you didn't find vfprintf() which is why I prefer to raise my hand ;-) > 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. Yeah that's ugly. In nolibc-test we now have two build targets so that we can more easily verify the compatibility between the default libc and nolibc, so my recommendation would be to stick to a common subset of both libcs, but not to rely on nolibc-specific stuff that could make tests harder to debug. Regards, Willy
On Thu, Apr 06, 2023 at 04:20:29PM +0200, Willy Tarreau wrote: > On Thu, Apr 06, 2023 at 02:56:28PM +0100, Mark Brown wrote: > > 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. > In fact we already have vfprintf(), and printf() is based on it, so > wouldn't it just be a matter of adding vprintf() that calls vfprintf() > for your case ? Maybe just something like this : > static int vprintf(const char *fmt, va_list args) > { > return vfprintf(stdout, fmt, args); > } > It's possible I'm missing something, but it's also possible you didn't > find vfprintf() which is why I prefer to raise my hand ;-) Oh, yes - I just didn't find that. Can't remember what I searched for but it didn't match. > > 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. > Yeah that's ugly. In nolibc-test we now have two build targets so that > we can more easily verify the compatibility between the default libc and > nolibc, so my recommendation would be to stick to a common subset of both > libcs, but not to rely on nolibc-specific stuff that could make tests > harder to debug. For these features we simply never want to run with a proper libc since if we use a libc which has support for the features then we can't meaningfully interact with them. We're trying to test interfaces that libc is supposed to use.
On Thu, Apr 06, 2023 at 03:32:20PM +0100, Mark Brown wrote: > On Thu, Apr 06, 2023 at 04:20:29PM +0200, Willy Tarreau wrote: > > On Thu, Apr 06, 2023 at 02:56:28PM +0100, Mark Brown wrote: > > > > 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. > > > In fact we already have vfprintf(), and printf() is based on it, so > > wouldn't it just be a matter of adding vprintf() that calls vfprintf() > > for your case ? Maybe just something like this : > > > static int vprintf(const char *fmt, va_list args) > > { > > return vfprintf(stdout, fmt, args); > > } > > > It's possible I'm missing something, but it's also possible you didn't > > find vfprintf() which is why I prefer to raise my hand ;-) > > Oh, yes - I just didn't find that. Can't remember what I searched for > but it didn't match. No problem. I just remembered it existed because we just received a new test for it a few days ago ;-) > > > 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. > > > Yeah that's ugly. In nolibc-test we now have two build targets so that > > we can more easily verify the compatibility between the default libc and > > nolibc, so my recommendation would be to stick to a common subset of both > > libcs, but not to rely on nolibc-specific stuff that could make tests > > harder to debug. > > For these features we simply never want to run with a proper libc since > if we use a libc which has support for the features then we can't > meaningfully interact with them. We're trying to test interfaces that > libc is supposed to use. Indeed, this totally makes sense then! But I think you get the idea of what I was suggesting which is to try to avoid getting trapped by a single implementation in general, by using portable stuff as much as possible. Cheers, Willy
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,