[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <200911301101.59416.rusty@rustcorp.com.au>
Date: Mon, 30 Nov 2009 11:01:59 +1030
From: Rusty Russell <rusty@...tcorp.com.au>
To: Ingo Molnar <mingo@...e.hu>
Cc: Tejun Heo <tj@...nel.org>, Stephen Rothwell <sfr@...b.auug.org.au>,
"Fr??d??ric Weisbecker" <fweisbec@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Christoph Lameter <cl@...ux-foundation.org>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: percpu tree build warning
On Sun, 29 Nov 2009 05:10:19 pm Ingo Molnar wrote:
> * Rusty Russell <rusty@...tcorp.com.au> wrote:
> > [...] Again, I'm explaining what you should already know before
> > sending email about this stuff.
> > [...]
> > Stupidest debate ever.
>
> What i am making is a somewhat subtle technical argument and making any
> progress on it needs at least a minimal form of a working debate. I do
> not claim i am right, but still you are dismissing my arguments in a
> rather nasty way.
You're right, I was overly abrupt. Apologies.
You have a point: the compile-time restrictions on per-cpu misuse was nice. I know, I wrote it :) But as we start to pass more per-cpu pointers around, it breaks down. So the new sparse annotations are a better fit, and cover more.
The separate namespace was an unintended side-effect, and not one I'm fond
of. Unfortunately it became more attractive now static-scope per-cpu vars
are banned for some platforms. But having two names meaning different things
is bad for tags, grep and casual readers (your example is trivial enough that
we don't care, I agree).
> ... alas, i dont care _that_ much about this and i dont think my
> concerns deserved your ad hominem attacks so i see no point in further
> participating in this thread.
I just reviewed what I sent. I don't think my attacks were ad-hominem.
There are very few people on this list who gracefully accept when they are wrong. The rest of us try to come grasp at some alternate criticism instead, flailing around attacking minor surrounding issue to save face.[1]
This behavior is unbecoming and frankly embarrassing, but at least it usually
motivates people to review the patches! And, code being what it is, they find some nit to pick and feel better about their prior mistake.
Unfortunately, this debate *is* stupid because neither of us are really going to do anything about it: ie. it did not cause either of us to review code. It is also stupid because I know I'm not telling you anything you can't think of yourself. Finally, it's stupid because it's all been said before in commit messages and in previous posts.
Hope that clarifies,
Rusty.
[1] If anyone cared, I'm sure they could find excruciating lkml archive
examples of me doing this.
--
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