Message-ID: <20090824110040.GA4050@elte.hu>
Date:	Mon, 24 Aug 2009 13:00:40 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Josh Stone <jistone@...hat.com>, linux-kernel@...r.kernel.org,
	Jason Baron <jbaron@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Jiaying Zhang <jiayingz@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Lai Jiangshan <laijs@...fujitsu.com>
Subject: Re: [PATCH v3 2/4] tracing: Make syscall_(un)regfunc arch-specific


* Paul Mundt <lethal@...ux-sh.org> wrote:

> On Mon, Aug 24, 2009 at 11:56:52AM +0200, Ingo Molnar wrote:
> > * Paul Mundt <lethal@...ux-sh.org> wrote:
> > > I think this is the source of confusion, given that I expected the 
> > > interface would remain reasonable stable until all of the existing 
> > > users had had a chance to catch up. [...]
> > 
> > All existing upstream users of APIs were fixed up. Which was x86 and 
> > s390. (and yes, we initially missed s390)
> > 
> > Stable APIs are not how upstream Linux kernel development works - it 
> > would be way too inflexible.
> > 
> > Instead facility trees (such as the tracing tree) are either 
> > expected to convert all upstream API uses (which we did), or are 
> > supposed to provide different versions of APIs, if an API is so 
> > widespread (used by hundreds of callsites, etc.) that it's not 
> > reasonable to convert it in one go.
> 
> No Ingo, this is not what you did, this is what you did after the 
> breakage was pointed out to you. [...]

As i explained it to you back then the s390 support was 1) a few 
weeks old 2) got masked due to an unrelated thing. In any case the 
bug was real and it was fixed very quickly within an hour or so of 
the report in the usual workflow and without any argument about it, 
and in total agreement with the s390 folks.

And the thing is, s390 was always a pleasure to deal with. I cannot 
say the same about anything SH. SH always was a huge PITA to deal 
with (to me at least), mainly because you seem to have a false sense 
of entitlement: you think everyone else must be perfect and must not 
affect you while you can sit on your own little island not worrying 
about the rest of the world - who develops and tests core kernel 
facilities for you. It doesnt work like that.

> [...] And before that, you had:
> 
> commit 60d970c254b95ec7a0fc4c590b510253987b64a0
> Author: Ingo Molnar <mingo@...e.hu>
> Date:   Thu Aug 13 23:37:26 2009 +0200
> 
>     tracing: Fix syscall tracing on !HAVE_FTRACE_SYSCALLS architectures
> 
>     The new syscall_regfunc()/unregfunc() functions rely on
>     the existence of TIF_SYSCALL_FTRACE - but that TIF flag
>     is only offered by HAVE_FTRACE_SYSCALLS.
> 
>     Cc: Frederic Weisbecker <fweisbec@...il.com>
>     Cc: Jason Baron <jbaron@...hat.com>
>     Cc: Steven Rostedt <rostedt@...dmis.org>
>     Cc: Peter Zijlstra <peterz@...radead.org>
>     LKML-Reference: <new-submission>
>     Signed-off-by: Ingo Molnar <mingo@...e.hu>
> 
> Which you at least managed to catch before it went in to -next.

See that LKML-Reference tag? That patch too went out to lkml. Had 
you chosen to participate instead of just complaining you could 
have.

Then you intentionally chose the wrong workflow and now you are 
complaining 1) about an easily fixed bug that got addressed within 
an hour of it reported 2) about a workflow situation you yourself 
created. [and to which i suggested several alternatives how to fix 
it.]

You are not being constructive at all.

	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/

Powered by blists - more mailing lists