Messages in this thread | | | Date | Wed, 29 Nov 2017 07:57:38 -0500 | From | Steven Rostedt <> | Subject | Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON |
| |
On Thu, 23 Nov 2017 14:32:32 +0200 Vladislav Valtchev <vladislav.valtchev@gmail.com> 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
| |