linux-kernel - Re: [RFC patch 01/32] TRACE_EVENT: gradual semicolon removal

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]

Date:	Wed, 4 May 2011 00:01:01 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC patch 01/32] TRACE_EVENT: gradual semicolon removal

On Tue, May 03, 2011 at 05:26:57PM -0400, Mathieu Desnoyers wrote:
> * Steven Rostedt (rostedt@...dmis.org) wrote:
> > > * Why do this incrementally ?
> > 
> > Preaching to the choir?
> 
> I've been asked to explain myself on this topic by Frederic last time I
> posted this patchset, so I added the explanation to the changelog.

Explaining it in the cover letter is enough :)

> > 
> > > 
> > > After this preliminary patch, the semicolon removal can be done gradually
> > > without breaking the build: we can be in an intermediate state with some files
> > > having semicolons and others without. This is therefore good for
> > > bissectability, and seems like a nice way to bring in an internal API change
> > > without making developers suffer too much. Then, once things are stabilized, we
> > > can start modifying the Ftrace code to generate the more space-efficient arrays
> > > (possibly in a release-cycle or so), knowing that this enforces a strict
> > > requirement on semicolon removal.
> > 
> > Mathieu, I like the patch, but I think you explain too much ;)
> 
> Or too little, depending on the maintainer. ;-)

Well, I did never asked for 1000 lines of changelog ;)
The real problem with your previous set is that your arguments were
either too weak (double ";" in generated code doesn't alone justify
a massive change like this) or too foggy (the array of field
idea was not developed enough to be understanble whereas it was the
only sane reason for this massive change).

Just explain briefly that the end goal is for storing fields in an array
with a quick example and you are done with few dozen lines for
your changelog.

People simply don't review fat changelogs.
--
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/