From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4A65DC38A24 for ; Thu, 7 May 2020 19:07:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2B1C820870 for ; Thu, 7 May 2020 19:07:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728238AbgEGTHB (ORCPT ); Thu, 7 May 2020 15:07:01 -0400 Received: from smtprelay0085.hostedemail.com ([216.40.44.85]:49812 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726320AbgEGTHA (ORCPT ); Thu, 7 May 2020 15:07:00 -0400 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay02.hostedemail.com (Postfix) with ESMTP id ED28114547; Thu, 7 May 2020 19:06:59 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: pie60_3cdad48d2c733 X-Filterd-Recvd-Size: 2688 Received: from XPS-9350.home (unknown [47.151.136.130]) (Authenticated sender: joe@perches.com) by omf16.hostedemail.com (Postfix) with ESMTPA; Thu, 7 May 2020 19:06:58 +0000 (UTC) Message-ID: <96fe70f11245433ce4f19bffaf2d167dbf69a2a0.camel@perches.com> Subject: Re: [PATCH] sched/fair: Return true,false in voluntary_active_balance() From: Joe Perches To: Steven Rostedt Cc: Valentin Schneider , Jason Yan , mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, bsegall@google.com, mgorman@suse.de, linux-kernel@vger.kernel.org Date: Thu, 07 May 2020 12:06:56 -0700 In-Reply-To: <20200507144534.09abd685@gandalf.local.home> References: <20200507110625.37254-1-yanaijie@huawei.com> <20200507132828.1af39b80@gandalf.local.home> <20200507133024.18dbe349@gandalf.local.home> <20200507144534.09abd685@gandalf.local.home> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.36.1-2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-05-07 at 14:45 -0400, Steven Rostedt wrote: > On Thu, 07 May 2020 10:55:33 -0700 > Joe Perches wrote: > > > > If anything, we can teach people to try to understand their fixes, to see > > > if something is really a fix or not. Blindly accepting changes like this, > > > is no different than blindly submitting patches because some tool says its > > > an issue. > > > > > > > > Most people seem to prefer bool returns with apparent bool constants > > even though true and false are enumerator constants (int) of 1 and 0 > > in the kernel. > > > > from include/linux/stddef.h: > > > > enum { > > false = 0, > > true = 1 > > }; > > Sure, do that for new code, but we don't need these patches popping up for > current code. That is, it's a preference not a bug. People describe changes as a "fix" all the time for stuff that isn't an actual fix for a logic defect but is instead an update to a particular style preference. Then the "fix" word causes the patch to be rather uselessly applied to stable trees by AUTOSEL. It's especially bad when the 'Fixes: ("description")' tag is also added. It's a difficult thing to regulate and I don't believe a good mechanism would be possible to add to checkpatch or coccinelle to help isolate these things. git diff -w sometimes helps, but that's not really a thing that checkpatch could do. Any suggestions?