From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751196AbdJRRNW (ORCPT ); Wed, 18 Oct 2017 13:13:22 -0400 Received: from mga02.intel.com ([134.134.136.20]:42011 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750807AbdJRRNV (ORCPT ); Wed, 18 Oct 2017 13:13:21 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,397,1503385200"; d="scan'208";a="1232286490" Date: Wed, 18 Oct 2017 20:13:09 +0300 From: Jarkko Sakkinen To: James Bottomley Cc: SF Markus Elfring , Dan Carpenter , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?iso-8859-1?Q?H=FCwe?= , Stefan Berger , LKML , kernel-janitors@vger.kernel.org Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations Message-ID: <20171018171309.f7idf76ccvofpnpk@linux.intel.com> References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <20171016183139.otyh3m5c5yurtmow@linux.intel.com> <20171016183512.3bz6x4b6lbhpbkje@linux.intel.com> <20171017085124.pkrjzghcf5wmcydc@mwanda> <1508255833.3129.33.camel@HansenPartnership.com> <20171018151010.r4ojcpzs5l7rpt6r@linux.intel.com> <1508342988.3958.5.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1508342988.3958.5.camel@HansenPartnership.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2017 at 09:09:48AM -0700, James Bottomley wrote: > On Wed, 2017-10-18 at 18:10 +0300, Jarkko Sakkinen wrote: > > On Tue, Oct 17, 2017 at 08:57:13AM -0700, James Bottomley wrote: > > > > > > On Tue, 2017-10-17 at 11:25 +0200, SF Markus Elfring wrote: > > > > > > > > > > > > > > > > > > > Fixes is only for bug fixes.  These don't fix any bugs. > > > > > > > > How do you distinguish these in questionable source code > > > > from other error categories or software weaknesses? > > > > > > A style change is one that doesn't change the effect of the > > > execution. > > >  These don't actually even change the assembly, so there's > > > programmatic > > > proof they're not fixing anything. > > > > > > Bug means potentially user visible fault.  In any bug fix commit > > > you > > > should document the fault and its effects on users so those > > > backporting > > > can decide if they care or not. > > > > > > James > > > > OK, I'll adjust my definition of a bug :-) > > Subsystems are free to define bugs in any reasonable way.  However, > there are two things to note here: > > 1. The style guide is just that, a guide; it's not hard and fast rules. >  That means that violations aren't bugs in the usual sense. >  However, new code should mostly follow it and if it doesn't, there > should be a good reason to go against the guide which should be > explained in the change log. > 2. The coding style evolves, so older drivers usually don't conform. >  Classifying coding style issues as bugs leads to tons of patches > "fixing" older drivers, some of which actually end up breaking the > drivers in subtle ways which take ages to be found (at least that's > what we've seen in SCSI). > > James Makes sense. Thanks for verbose explanation. /Jarkko