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