linux-kselftest.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Alan Maguire <alan.maguire@oracle.com>
Cc: rostedt@goodmis.org, shuah@kernel.org, mingo@redhat.com,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	naveen.n.rao@linux.vnet.ibm.com, colin.king@canonical.com
Subject: Re: [PATCH 2/2] ftrace/selftest: absence of modules/programs should trigger unsupported errors
Date: Fri, 7 Feb 2020 17:50:11 +0900	[thread overview]
Message-ID: <20200207175011.5312fcb9be04c83ec9eb548c@kernel.org> (raw)
In-Reply-To: <alpine.LRH.2.20.2002070818310.21581@dhcp-10-175-186-149.vpn.oracle.com>

On Fri, 7 Feb 2020 08:27:13 +0000 (GMT)
Alan Maguire <alan.maguire@oracle.com> wrote:

> On Fri, 7 Feb 2020, Masami Hiramatsu wrote:
> 
> > Hi Alan,
> > 
> > On Thu,  6 Feb 2020 15:09:20 +0000
> > Alan Maguire <alan.maguire@oracle.com> wrote:
> > 
> > > In a number of cases, the ftrace tests check for the presence of
> > > ftrace testing-related modules (ftrace-direct, trace-printk) and
> > > programs (checkbashisms), returning exit_unresolved if these
> > > are not found.  The problem is, exit_unresolved causes execution
> > > of ftracetest to return an error, when really our tests are
> > > failing due to not having the requisite kernel configuration/tools
> > > present, which is I think more of an unsupported error condition.
> > > With these fixed, we see no unresolved test cases and ftracetest
> > > returns success ("ok" when run via kselftest).
> > 
> > If your problem is to pass the test even if you don't test the
> > feature, please change the ftracetest itself instead of replacing
> > unresolved with unsupported. Those notice different situation.
> > 
> > unresolved - Testcase can not find some tools or helper drivers
> >              which are required for this testcase.
> > 
> > unsupported - Kernel does not have tested feature because of
> >               the version or the configuration.
> > 
> > Obviously the unresolved is a test environment issue. No test-module
> > doesn't mean no feature to be tested.
> > Could you tell me the reason why you can't install those required
> > tools and modules on the test environment?
> > 
> 
> Sure! In my case, I'm testing a distro production kernel,
> where I can't control the CONFIG variable settings.  In
> this case, ideally I'd like the tests to return success
> if no problems with ftrace were detected, even if some
> of the tests could not be run due to missing modules
> and programs.

OK, for modules, we need to find another way to solve the issue.
But how about checkbashisms? you can download and build it.

https://sources.debian.org/src/devscripts/2.20.2/

For the modules, you might be able to build it from kernel
source code as out-of-tree modules, or not?
(hmm, how do the other test handle it...?)

>  As you suggest above (unless I'm
> misunderstanding), this could be accomplished by modifying
> ftracetest itself.  Would doing something like what is done
> for UNSUPPORTED_RESULT (defaults to 0, but can be set to
> 1 via --fail-unsupported, such that ftracetest returns
> 1 if we encounter unsupported results) make sense for
> the unresolved case too?

Yes, but at first could you try to setup your testing environment?
If you are officially testing your distro kernel, the distro
might need to be tested with full-set of testcases.

If not (like you are testing kernel for fun :)), you can just
make your custom set of testcases. (just remove those test files)

Thank you,


-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2020-02-07  8:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 15:09 [PATCH 0/2] ftrace/selftests: clean up failure cases Alan Maguire
2020-02-06 15:09 ` [PATCH 1/2] ftrace/selftests: workaround cgroup RT scheduling issues Alan Maguire
2020-02-07  6:14   ` Masami Hiramatsu
2020-02-10 22:18     ` Steven Rostedt
2020-02-10 22:53       ` Masami Hiramatsu
2020-02-06 15:09 ` [PATCH 2/2] ftrace/selftest: absence of modules/programs should trigger unsupported errors Alan Maguire
2020-02-07  4:43   ` Masami Hiramatsu
2020-02-07  8:27     ` Alan Maguire
2020-02-07  8:50       ` Masami Hiramatsu [this message]
2020-02-19  9:55         ` Alan Maguire

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=20200207175011.5312fcb9be04c83ec9eb548c@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=alan.maguire@oracle.com \
    --cc=colin.king@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).