mbox series

[0/2] kselftest: Support nolibc

Message ID 20230405-kselftest-nolibc-v1-0-63fbcd70b202@kernel.org
Headers
Series kselftest: Support nolibc |

Message

Mark Brown April 6, 2023, 1:56 p.m. UTC 
  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,

Comments

Willy Tarreau April 6, 2023, 2:20 p.m. UTC | #1 
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
Mark Brown April 6, 2023, 2:32 p.m. UTC | #2 
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.
Willy Tarreau April 6, 2023, 4:22 p.m. UTC | #3 
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