On Tue, Nov 19, 2024 at 4:53 PM Steven Rostedt <rost...@goodmis.org> wrote: > > On Tue, 19 Nov 2024 16:31:40 +0100 > Alice Ryhl <alicer...@google.com> wrote: > > > > Would you be able to create some simple code to do that? If you add > > > something in the rust sample code, I'll add it to the ftrace selftests. > > > > Sure, I'll submit a sample which does that for the 6.14 cycle. > > Is it because you don't have time this week or is it because you think it's > just too late to add code during the merge window? If it's the former, then > sure, we can wait. But if you want to wait just because we are in the merge > window, you don't need to. For things that add testing, it's OK to send > even this late in the game. What I and many should not accept, is any > active development on the kernel itself. Adding a sample module to be able > to test if things are working properly does not fall under that category. > > The reason I ask, is I feel nervous about sending code to Linus that I > personally do not test. It's not a show stopper. I'll still send your > patches without or without this change. Before I send a pull request to > Linus, I like to run one last smoke test on the code, and that's when I > discovered I don't really have any tests to test your code.
Mostly because of the merge window, though also because waiting would let me use things landing in 6.13 through other maintainer trees; this would let me have the sample declare a miscdevice. But what I can submit now is this: create a Rust file that exposes a function which just triggers a tracepoint, and then I can call that function from C somewhere in the ftrace selftests, and then afterwards the C code could assert that the tracepoint got triggered. Is there an existing ftrace test that I can look at to base my work on? Alice
