Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON

[Steven Rostedt]

On Thu, 23 Nov 2017 14:32:32 +0200
Vladislav Valtchev <vladislav.valtchev@xxxxxxxxx> wrote:

> Agree.
> We might also add an if (!isdigit(buf)) die() before return, but I understand
> that, on the other side, we might not need to check the kernel's behavior
> this way. We might ultimately trust the kernel [every part of it] and save
> trace-cmd's code from having a ton of verbose sanity checks like this one.
> 
> It's all about trade-offs, clearly.
> Therefore, I'm fine with whatever trade-off you believe is better for trace-cmd.

Let's think about what the user wants.

If you do a "trace-cmd stat" what are you looking for? You want to see
what ftrace operations are available. Now let's say we do something
weird, or someone has some weird modified kernel, and the stack tracer
shows something that trace-cmd doesn't expect. With a die, it kills the
tool.

Would you like it if you ran "trace-cmd stat" and got it crashed with
an error message saying the kernel is doing something it doesn't
understand? To me, I'd be pissed. I would be cursing at trace-cmd
saying "I don't give a frick about that, show me what you do know!"

Now, do you think having a "die" is good there?

The only "die"s I have in trace-cmd stat is failure to allocate. That's
because the tool itself is then corrupted. In no case should trace-cmd
stat die because it doesn't understand something. And really, that
should be the entire case for trace-cmd. The only reason to call die is
if there's a failure in the tool itself where it can't continue (failed
memory allocations are usually severe).

-- Steve