Messages in this thread | | | Date | Thu, 10 Dec 2020 11:08:54 +0900 | From | Masami Hiramatsu <> | Subject | Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring buffer timestamps |
| |
On Wed, 9 Dec 2020 09:49:19 -0500 Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 9 Dec 2020 08:39:54 +0900 > Masami Hiramatsu <mhiramat@kernel.org> 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.
Oh I thought you considered the case that the library version differences between the binary and execute environment.
> > > > (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" ;-)
Yeah, so now if it can not run, user can solve it by installing libtracefs:)
Thank you,
-- Masami Hiramatsu <mhiramat@kernel.org>
| |