linux-kernel - Re: [PATCH v3 00/23] perf: Add infrastructure and support for Intel PT

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: <20140811054625.GC7489@gmail.com>
Date:	Mon, 11 Aug 2014 07:46:25 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	Robert Richter <rric@...nel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <ak@...ux.intel.com>, kan.liang@...el.com
Subject: Re: [PATCH v3 00/23] perf: Add infrastructure and support for Intel
 PT

* Alexander Shishkin <alexander.shishkin@...ux.intel.com> wrote:

> Hi Peter and all,
> 
> Here's a new version of PT support patchset, this time including PT and
> BTS drivers and a few more tweaks to the core. I still left out some bits
> like core dump support for now. Tooling support is not included in this
> series so that it's easier to review the kernel bits, I suppose it's best
> to send it separately, since it's quite a huge patchset of its own.

I know what this series is about, but pretty please, always include a 
complete introduction, or at least a link to a good introdcution, 
which spells out the whole problem space, the proposed solution, its 
various design trade-offs (if any), links to tooling for people who 
want to have a look at both sides, list of items not yet properly 
implemented [or a clear statement that it's all ready to go in your 
view], etc., in as much detail as possible!

The reason is that many reviewers will skip early versions of patch 
series, especially if they see something trivially objectionable in 
it. Why spend effort on reviewing something that might never see the 
light of the day? But if later re-sends of the series skip essential 
information it's harder to 'jump in' and offer useful feedback...

If you worry about being overly verbose in your patch series 
announcement, in my experience as a kernel maintainer it's literally 
impossible for kernel developers to over-do the description of a new 
feature. (Steve Rostedt tries on occasion but even he never succeeded 
in the past. I claim this is due to software developer brain 
structure, but I digress.)

It's also absolutely fine to cut & paste an old 0/N description over 
and over again, and to update it only as far as the patches have 
changed.

A good rule of thumb is to have at least as many sentences in the 0/N 
description as there are patches in the series, i.e. 23 sentences in 
this instance. Preferably scaled up by complexity.

Thanks,

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