Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring buffer timestamps
From: Steven Rostedt
Date: Wed Dec 09 2020 - 09:50:32 EST
On Wed, 9 Dec 2020 08:39:54 +0900
Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote:
> > OK. I'll look at how to make this for both cases (embedded and not).
> > Because, my current case is to copy the selftests to the machine and run
> > them there. So my use case requires the build to happen at test time. But I
> > can make it where it wont build if the binary already exists.
>
> For that case, what about just "make clean" before copy, then the binary
> will be removed?
I just meant that the binary build should not depend on anything outside
the directory. It should be able to be built if you just copy the
ftracetest directory and run there.
>
> >
> > > (currently I returns UNRESOLVED when the test target kmodule is not found)
> >
> > I used UNTESTED for a couple of reasons. I figured "UNRESOLVED" was for
> > lack of kernel features or modules. But this is not a lack of the kernel,
> > but a lack of user space. If something in user space is lacking (a tool,
> > library, or binary), then I thought UNTESTED would be a better option. But
> > if you have a strong opinion on it, I'll change it to UNRESOLVED, otherwise
> > I'll keep UNTESTED.
>
> The idea of UNTESTED/UNRESOLVED (and UNSUPPORTED) came from POSIX standard,
> it is expained in dejagnu's manual:
>
> https://www.gnu.org/software/dejagnu/manual/A-POSIX-Conforming-Test-Framework.html
>
> In this case, user can build the user space binary for the environment but
> does't, so I think UNRESOLVED will fit to that case.
>
> So strictly speaking, UNTESTED is just a placeholder which will be implemented
> in the future. (hmm, it will be a good chance to write a document for it)
OK, I'll change it to UNRESOLVED. One reason I used UNTESTED, is that the
build wont happen until libtracefs is packaged and released (or you
download and build it yourself). And it's just getting ready now. So in
essence, this is currently just a "placeholder" ;-)
-- Steve