From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751818AbdJRQJx (ORCPT ); Wed, 18 Oct 2017 12:09:53 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:33396 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751224AbdJRQJv (ORCPT ); Wed, 18 Oct 2017 12:09:51 -0400 Message-ID: <1508342988.3958.5.camel@HansenPartnership.com> Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations From: James Bottomley To: Jarkko Sakkinen 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 Date: Wed, 18 Oct 2017 09:09:48 -0700 In-Reply-To: <20171018151010.r4ojcpzs5l7rpt6r@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> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Date: Wed, 18 Oct 2017 16:09:48 +0000 Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations Message-Id: <1508342988.3958.5.camel@HansenPartnership.com> List-Id: 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> In-Reply-To: <20171018151010.r4ojcpzs5l7rpt6r@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: Jarkko Sakkinen 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 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bedivere.hansenpartnership.com ([66.63.167.143]:33396 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751224AbdJRQJv (ORCPT ); Wed, 18 Oct 2017 12:09:51 -0400 Message-ID: <1508342988.3958.5.camel@HansenPartnership.com> Subject: Re: [PATCH 0/4] char-TPM: Adjustments for ten function implementations From: James Bottomley To: Jarkko Sakkinen 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 Date: Wed, 18 Oct 2017 09:09:48 -0700 In-Reply-To: <20171018151010.r4ojcpzs5l7rpt6r@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> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-integrity-owner@vger.kernel.org List-ID: 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