From: Willy Tarreau <w@1wt.eu> To: Mark Brown <broonie@kernel.org> Cc: Shuah Khan <shuah@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] kselftest: Support nolibc Date: Thu, 6 Apr 2023 16:20:29 +0200 [thread overview] Message-ID: <ZC7VLXGpB8PRdj12@1wt.eu> (raw) In-Reply-To: <20230405-kselftest-nolibc-v1-0-63fbcd70b202@kernel.org> 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
WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu> To: Mark Brown <broonie@kernel.org> Cc: Shuah Khan <shuah@kernel.org>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, "Paul E. McKenney" <paulmck@kernel.org>, linux-arm-kernel@lists.infradead.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] kselftest: Support nolibc Date: Thu, 6 Apr 2023 16:20:29 +0200 [thread overview] Message-ID: <ZC7VLXGpB8PRdj12@1wt.eu> (raw) In-Reply-To: <20230405-kselftest-nolibc-v1-0-63fbcd70b202@kernel.org> 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-06 14:21 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-06 13:56 [PATCH 0/2] kselftest: Support nolibc Mark Brown 2023-04-06 13:56 ` Mark Brown 2023-04-06 13:56 ` [PATCH 1/2] " Mark Brown 2023-04-06 13:56 ` Mark Brown 2023-04-06 13:56 ` [PATCH 2/2] kselftest/arm64: Convert za-fork to use kselftest.h Mark Brown 2023-04-06 13:56 ` Mark Brown 2023-04-06 14:20 ` Willy Tarreau [this message] 2023-04-06 14:20 ` [PATCH 0/2] kselftest: Support nolibc Willy Tarreau 2023-04-06 14:32 ` Mark Brown 2023-04-06 14:32 ` Mark Brown 2023-04-06 16:22 ` Willy Tarreau 2023-04-06 16:22 ` Willy Tarreau
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ZC7VLXGpB8PRdj12@1wt.eu \ --to=w@1wt.eu \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=paulmck@kernel.org \ --cc=shuah@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.