linux-kernel - Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring buffer timestamps

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201209094919.31724179@gandalf.local.home>
Date:   Wed, 9 Dec 2020 09:49:19 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Masami Hiramatsu <mhiramat@...nel.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring
 buffer timestamps

On Wed, 9 Dec 2020 08:39:54 +0900
Masami Hiramatsu <mhiramat@...nel.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.

> 
> >   
> > > (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