[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1508244757.4234.60.camel@linux.vnet.ibm.com>
Date: Tue, 17 Oct 2017 08:52:37 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: Alexander.Steffen@...ineon.com
Cc: linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
andriy.shevchenko@...ux.intel.com, elfring@...rs.sourceforge.net,
linux-integrity@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org,
benh@...nel.crashing.org, clabbe.montjoie@...il.com,
jarkko.sakkinen@...ux.intel.com, jgunthorpe@...idianresearch.com,
jsnitsel@...hat.com, kgold@...ux.vnet.ibm.com, mpe@...erman.id.au,
nayna@...ux.vnet.ibm.com, paulus@...ba.org, PeterHuewe@....de,
Stefan Berger <stefanb@...ux.vnet.ibm.com>
Subject: Re: [PATCH 3/4] char/tpm: Improve a size determination in nine
functions
On Tue, 2017-10-17 at 11:50 +0000, Alexander.Steffen@...ineon.com
wrote:
> > > Replace the specification of data structures by pointer dereferences
> > > as the parameter for the operator "sizeof" to make the corresponding
> > > size
> > > determination a bit safer according to the Linux coding style
> > > convention.
> >
> >
> > This patch does one style in favor of the other.
>
> I actually prefer that style, so I'd welcome this change :)
Style changes should be reviewed and documented, like any other code
change, and added to Documentation/process/coding-style.rst or an
equivalent file.
> > At the end it's Jarkko's call, though I would NAK this as I think some
> > one already told this to you for some other similar patch(es).
> >
> >
> > I even would suggest to stop doing this noisy stuff, which keeps people
> > busy for nothing.
>
> Cleaning up old code is also worth something, even if does not
> change one bit in the assembly output in the end...
Wow, you're opening the door really wide for all sorts of trivial
changes! Hope you have the time and inclination to review and comment
on all of them. I certainly don't.
There is a major difference between adding these sorts of checks to
the tools in the scripts directory or even to the zero day bots that
catch different sorts of errors, BEFORE code is upstreamed, and
patches like these, after the fact.
After the code has been upstreamed, it is a lot more difficult to
justify changes like this. It impacts both code that is being
developed AND backporting bug fixes.
Mimi
Powered by blists - more mailing lists