Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp4616278imw; Tue, 12 Jul 2022 11:03:11 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sBBg4bh+asLkKw93sXj359fUXwllqGvl4sWLgYTPpeJ7UGWRu82PBMyeNg2Wt5Jm1IXxx4 X-Received: by 2002:a17:907:1dce:b0:72b:40c4:deec with SMTP id og14-20020a1709071dce00b0072b40c4deecmr17201721ejc.70.1657648991194; Tue, 12 Jul 2022 11:03:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657648991; cv=none; d=google.com; s=arc-20160816; b=QUv6Tpp3Tor+Bz5WRoXfy4gaErt3UebZOHVUvCa1CXa6ph4T5VgBM4gY2+YQkK8C9y /eo4/1KiZmwmzSreE6pIQWewX0phIiSH3n7LbqsroiMLo3WYnhUo/i4uQ2s6McaHtrxR hMfjEA/UzSQkZW3uA7ZF7ObWsi7rSJ5oHbbjL2FyyWIS0EFYBWtm9XHmh3ncbxaqhzit zUaOkaImEAo5q2jTF5CkN9nmwM2d1XTDwazQi/TZqtAvlR9H1mZU+bhO1AusEnBn0Tup +xIO51V3tFT6pevNq/7//wyL6aUjUUsdw44DhlBJ/8twNEUutNpgykXwkzEPG89JNz13 kuCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=Lrmf0xJwdnLYOC59EqgINkhGcrTU848cZg5L8rwE7Xc=; b=fX20OMm8+jKJtCmyccCZvgcoIt0yaX5BYEY57FFsLUAJHlXoBNLbFVfFuwE+xPTwpc xHeSFMtIpPyEAvIMUmoi6yu6VKQpegqFDmuB7JnddhhLzuPxd3qONdNEqcsA+W/rwGHE 82C+ST5kn44JxWZbeHaFhcgLsMB/mHVusU7efk9R+p4aqWS1MKPUneFI4jjqXb/Txkhl IfwZPxOsbN0MMyn958WPxe6/H/CUbN72RFnf5BczVZFWsX68Zw8t6weNeD7wBmWxQeJa /B3XdrvWybF5te/yD9x96IeR+i8CyUs9x4zMJ81fKSYH8Eo4F/PKzV7fxJXsAJsU8fAE GLhw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mm27-20020a170906cc5b00b0072b3338c3absi11459239ejb.878.2022.07.12.11.02.38; Tue, 12 Jul 2022 11:03:11 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233321AbiGLRuF (ORCPT + 99 others); Tue, 12 Jul 2022 13:50:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52202 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230122AbiGLRuD (ORCPT ); Tue, 12 Jul 2022 13:50:03 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E4984D14A; Tue, 12 Jul 2022 10:50:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id AB0F6B81B89; Tue, 12 Jul 2022 17:50:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 806FDC3411C; Tue, 12 Jul 2022 17:49:58 +0000 (UTC) Date: Tue, 12 Jul 2022 13:49:56 -0400 From: Steven Rostedt To: Zheng Yejian Cc: , , , , , Subject: Re: [PATCH] tracing/histograms: Simplify create_hist_fields() Message-ID: <20220712134956.4acb90a3@gandalf.local.home> In-Reply-To: <20220630013152.164871-1-zhengyejian1@huawei.com> References: <20220630013152.164871-1-zhengyejian1@huawei.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Jun 2022 09:31:52 +0800 Zheng Yejian wrote: > When I look into implements of create_hist_fields(), I think there can be > following two simplifications: > 1. If something wrong happened in parse_var_defs(), free_var_defs() would > have been called in it, so no need goto free again after calling it; > 2. After calling create_key_fields(), regardless of the value of 'ret', it > then always runs into 'out: ', so the judge of 'ret' is redundant. > > No functional changes. I applied this but removed the "No functional changes" because it is a functional change. The end result may be the same, but the flow is different, and that means it changed functionally. The only time "No functional changes" should be stated is if you move code around or change #ifdefs to perform the same action. IOW, if the assembly produced by the compiler is the same before and after your change, you can say "No functional changes", otherwise don't ever say that. This is important, because if a bisect lands on this, people may think the bisect is incorrect, when in reality it could be the cause of the bug (I just had this happen to me with another commit that had "No functional changes" :-p ) -- Steve > > Signed-off-by: Zheng Yejian