linux-kernel - Re: [PATCH 3/3] cpufreq: Prevent problems in update_policy_cpu() if last_cpu == new

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] [day] [month] [year] [list]

Message-ID: <52319A40.30703@linux.vnet.ibm.com>
Date:	Thu, 12 Sep 2013 16:11:04 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Viresh Kumar <viresh.kumar@...aro.org>,
	Stephen Warren <swarren@...dotorg.org>,
	"cpufreq@...r.kernel.org" <cpufreq@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] cpufreq: Prevent problems in update_policy_cpu()
 if last_cpu == new_cpu

On 09/12/2013 04:10 PM, Rafael J. Wysocki wrote:
> On Thursday, September 12, 2013 12:42:29 PM Srivatsa S. Bhat wrote:
>> On 09/12/2013 12:14 PM, Viresh Kumar wrote:
>>> On 12 September 2013 12:00, Srivatsa S. Bhat
>>> <srivatsa.bhat@...ux.vnet.ibm.com> wrote:
>>>> Looking at the rate at which we are bumping into each others thoughts, I think
>>>> maybe we should switch from email to IRC ;-) ;-)
>>>
>>> Unbelievable, Even I thought so this morning :)
>>>
>>> One more thing that I wanted to say for some other threads..
>>> Your changelogs are simply superb.. The amount of information that you put in
>>> them is fantastic.. 
>>
>> Thank you! :-) I'm glad to hear that!
>>
>> Believe it or not, I spend almost an equal (if not more) amount of time ensuring
>> that I get the changelog absolutely right, compared to the time I spend actually
>> writing the code. The reason is that, I have been pleasantly surprised by the
>> power of the changelog in numerous occasions: the very act of composing a proper 
>> changelog forces me to think *much* more clearly than when writing code. And it
>> often gives me the opportunity to rethink the *entire* approach/solution and not
>> just the implementation, since I need to explain the full context in it, not
>> just what the code does. And *that* exercise can reveal more complex/subtle bugs
>> than mere code review can ever do. That's why I put so much emphasis on writing
>> a perfect changelog :-) [Believe it or not, I have had times when I figured out
>> that my entire solution was utterly nonsensical when I began writing the changelog,
>> *after* reviewing and testing the code! ... and of course I had to rework the
>> entire patch! ;-( ]
>>
>> And to prevent myself from going overboard with writing the changelog (like making
>> it way too verbose or convoluted with too much detail), I have a simple mechanism/
>> handy rule in place:
>>
>> The changelog should be such that, whoever reads the changelog should feel that
>> the time he spent reading it was totally worth it. IOW, it should not simply
>> regurgitate what is already obvious from the code. Instead it should provide
>> insights into the subtle aspects or tradeoffs relevant to the patch; in short, it
>> should explain the "_why_ behind the _what_" as clearly and in as few words as
>> possible :-)
>>
>> Well, atleast I _try_ to stick to that rule :-)
> 
> Can you please prepare a patch against Documentation/SubmittingPatches with the
> above paragraph in it?  Seriously.
> 

Sure, I'd be delighted to :-)

> There are people who don't really see a reason for writing good patch
> changelogs.
> 

Regards,
Srivatsa S. Bhat

--
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/