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

Date:	Thu, 12 Sep 2013 12:42:29 +0530
From:	"Srivatsa S. Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>
To:	Viresh Kumar <viresh.kumar@...aro.org>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	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 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 :-)

> I never do it that way and so get caught by Rafael a number
> of times :)
> 

Hehe ;-)

> Need to learn this from you for sure :)
> 
> Btw, I am on Freenode for many Linaro channels.... Where can I find you on
> IRC? (Haven't sent this in a private mail as others might also find it useful)
> 

You can find me on ##kernel on freenode. Or, Rafael has a #pm channel for power
management discussions on tinc.sekrit.org.

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/