From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754028AbdK2M5l (ORCPT ); Wed, 29 Nov 2017 07:57:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:48404 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750708AbdK2M5k (ORCPT ); Wed, 29 Nov 2017 07:57:40 -0500 DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D08D921924 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=rostedt@goodmis.org Date: Wed, 29 Nov 2017 07:57:38 -0500 From: Steven Rostedt To: Vladislav Valtchev Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON Message-ID: <20171129075738.0ccd7d84@gandalf.local.home> In-Reply-To: <1511440352.2719.34.camel@gmail.com> References: <20171122180202.9519-1-vladislav.valtchev@gmail.com> <20171122180202.9519-4-vladislav.valtchev@gmail.com> <20171122145002.17c39637@gandalf.local.home> <1511440352.2719.34.camel@gmail.com> X-Mailer: Claws Mail 3.14.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 23 Nov 2017 14:32:32 +0200 Vladislav Valtchev 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