[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9ea2c1c7-a07d-19c3-a2dc-0c69352d9558@users.sourceforge.net>
Date: Wed, 3 Jan 2018 09:41:04 +0100
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Darren Hart <dvhart@...radead.org>,
ibm-acpi-devel@...ts.sourceforge.net,
platform-driver-x86@...r.kernel.org
Cc: Henrique de Moraes Holschuh <hmh@....eng.br>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Andy Shevchenko <andy@...radead.org>,
Henrique de Moraes Holschuh <ibm-acpi@....eng.br>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org
Subject: Re: platform/x86/thinkpad_acpi: Adjustments for four function
implementations
> I understand it can be frustrating to encounter different policies
> across kernel maintainers.
The change acceptance is varying for special transformation patterns.
> You'll even run in to this with maintainers of the same subsystem
> from time to time.
Interesting, isn't it?
> I'm supportive of cleaning up old code in general,
Nice.
> and we routinely apply such patches as these developed with cocci.
Good to know …
> 1. This is init code )so any space savings is short lived)
Would you dare to achieve another small improvement there?
> So it isn't that we place a low value on coding style guidelines,
> but rather we place higher value on not perturbing code
I can follow this view in principle.
> we can't fully test without a demonstrable functional reasons to do so.
How do you think about to get a bit nicer run time characteristics?
Regards,
Markus
Powered by blists - more mailing lists