lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Jun 2014 00:02:09 +0300
From:	Stratos Karafotis <stratosk@...aphore.gr>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	Dirk Brandewie <dirk.brandewie@...il.com>,
	dirk.j.brandewie@...el.com, Viresh Kumar <viresh.kumar@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 6/7] cpufreq: intel_pstate: Trivial code cleanup

On 10/06/2014 11:43 μμ, Rafael J. Wysocki wrote:
> On Tuesday, June 10, 2014 11:14:53 PM Stratos Karafotis wrote:
>> On 10/06/2014 11:17 μμ, Rafael J. Wysocki wrote:
>>> On Tuesday, June 10, 2014 10:26:44 AM Dirk Brandewie wrote:
>>>> On 06/10/2014 08:31 AM, Rafael J. Wysocki wrote:
>>>>> On Tuesday, June 10, 2014 08:12:48 AM Dirk Brandewie wrote:
>>>>>> On 06/09/2014 02:01 PM, Stratos Karafotis wrote:
>>>>>>> Remove unnecessary blank lines.
>>>>>>> Remove unnecessary parentheses.
>>>>>>> Remove unnecessary braces.
>>>>>>> Put the code in one line where possible.
>>>>>>> Add blank lines after variable declarations.
>>>>>>> Alignment to open parenthesis.
>>>>>>>
>>>>>>
>>>>>> I don't have an issue with this patch in general but I would rather
>>>>>> the cleanup be done when there is a functional change in the given
>>>>>> hunk of code otherwise you are setting up a fence for stable/backporters
>>>>>> of functional changes in the future.
>>>>>
>>>>> I actually prefer separate cleanups so as to avoid doing multiple things
>>>>> in one patch.
>>>>>
>>>>> Rafael
>>>>>
>>>> I don't have strong feelings either way I was just trying to be kind
>>>> to the maintainers of distro kernels.
>>>
>>> And mixing fixes with cleanups in one patch doesn't do any good to them.
>>>
>>> Trust me, I used to work for a distro. :-)
>>>
>>
>> So, should I proceed and split the patch or drop it? :)
> 
> I'm not sure why you'd want to split it?

Forgive me, but I'm totally confused. I asked because you mentioned that
you prefer separate cleanups.
So, my question was if you want me to separate this patch into more (one
per change) or entirely drop it (because it would cause problems to backporters
or maintainers).

> That said you're changing things that are intentional.  For example,
> the
> 
> 	if (acpi_disabled
> 	    || ...)
> 
> is.  And the result of (a * 100) / b may generally be different from
> a * 100 / b for integers (if the division is carried out first).

I thought that (a * 100) / b is always equivalent to a * 100 / b.


Stratos

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ