All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: shuah@kernel.org, linux-kselftest@vger.kernel.org,
	linux-sgx@vger.kernel.org,
	Dave Hansen <dave.hansen@linux.intel.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/2] selftests/sgx: Migrate to kselftest harness
Date: Tue, 18 May 2021 22:57:19 +0300	[thread overview]
Message-ID: <YKQcH2/5ENIp2Bps@kernel.org> (raw)
In-Reply-To: <YKP+CavM21klDHH8@kernel.org>

On Tue, May 18, 2021 at 08:49:00PM +0300, Jarkko Sakkinen wrote:
> On Mon, May 17, 2021 at 10:03:42AM -0700, Reinette Chatre wrote:
> > Hi Jarkko,
> > 
> > On 5/12/2021 2:53 PM, Jarkko Sakkinen wrote:
> > > Migrate to kselftest harness. Use a fixture test with enclave initialized
> > > and de-initialized for each of the existing three tests, in other words:
> > > 
> > > 1. One FIXTURE() for managing the enclave life-cycle.
> > > 2. Three TEST_F()'s, one for each test case.
> > > 
> > > This gives a leaps better reporting than before. Here's an example
> > > transcript:
> > > 
> > > TAP version 13
> > > 1..3
> > > 
> > > ok 1 enclave.unclobbered_vdso
> > > 
> > > ok 2 enclave.clobbered_vdso
> > > 
> > > ok 3 enclave.clobbered_vdso_and_user_function
> > > 
> > > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
> > > ---
> > > 
> > > v5:
> > > * Use TH_LOG() for printing enclave address ranges instead of printf(),
> > >    based on Reinette's remark.
> > 
> > Thank you for considering my feedback. The motivation for my comment was to
> > consider how this test output will be parsed. If these tests will have their
> > output parsed by automated systems then it needs to conform to the TAP13
> > format as supported by kselftest.
> > 
> > In your latest version the output printed during a successful test has been
> > changed, using TH_LOG() as you noted. From what I can tell this is the only
> > output addressed - failing tests continue to print error messages (perror,
> > fprintf) without consideration of how they will be parsed. My apologies, I
> > am not a kselftest expert to know what the best way for this integration is.
> > 
> > Reinette
> 
> It's a valid question, yes.
> 
> The problem is that only main.c can use kselftest macros because
> kselftest_harness.h pulls 
> 
> static int test_harness_run(int __attribute__((unused)) argc,
> 			    char __attribute__((unused)) **argv)
> 
> which will not end up having a call site (because there's no
> "TEST_HARNESS_MAIN").
> 
> The whole logging thing in kselftest harness is a bit ambiguous.
> Namely:
> 
> 1. There's a macro TH_LOG() defined in kselftest_harness.h, which
>    "internally" uses fprintf().
> 2. There's an inline function ksft_print_msg() in kselftest.h
>    using vsprintf().
> 
> To add to that, kselftest_harness.h internally prints by using
> ksft_print_msg(), and provides TH_LOG(), which does not use
> ksft_print_msg().
> 
> I don't really get the logic in all this.

I tried to split TH_LOG() as separate entity but it's not possible, as the
macros access a static variable called '_metadata'.

I'm not exactly sure how to proceed from this, if we want to make logging
consistent.

I would personally suggest to leave the error messages intact in load.c,
because there is no way to make them consistent, except by removing them.

/Jarkko

  reply	other threads:[~2021-05-18 19:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-12 21:53 [PATCH v5 1/2] selftests/sgx: Rename 'eenter' and 'sgx_call_vdso' Jarkko Sakkinen
2021-05-12 21:53 ` [PATCH v5 2/2] selftests/sgx: Migrate to kselftest harness Jarkko Sakkinen
2021-05-17 17:03   ` Reinette Chatre
2021-05-18 17:48     ` Jarkko Sakkinen
2021-05-18 19:57       ` Jarkko Sakkinen [this message]
2021-05-18 20:07         ` Reinette Chatre
2021-05-20 16:32           ` Jarkko Sakkinen

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=YKQcH2/5ENIp2Bps@kernel.org \
    --to=jarkko@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=shuah@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: link
Be 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.