From: Rusty Russell <rusty@rustcorp.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Tejun Heo <tj@kernel.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Fr??d??ric Weisbecker <fweisbec@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Christoph Lameter <cl@linux-foundation.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: percpu tree build warning
Date: Mon, 30 Nov 2009 11:01:59 +1030 [thread overview]
Message-ID: <200911301101.59416.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20091129064019.GA19916@elte.hu>
On Sun, 29 Nov 2009 05:10:19 pm Ingo Molnar wrote:
> * Rusty Russell <rusty@rustcorp.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.
next prev parent reply other threads:[~2009-11-30 5:16 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-25 10:42 linux-next: percpu tree build warning Stephen Rothwell
2009-11-25 10:50 ` Ingo Molnar
2009-11-25 11:14 ` Rusty Russell
2009-11-25 11:58 ` Ingo Molnar
2009-11-25 12:39 ` Tejun Heo
2009-11-25 12:31 ` Tejun Heo
2009-11-25 13:40 ` Ingo Molnar
2009-11-25 15:12 ` Tejun Heo
2009-11-26 22:16 ` Rusty Russell
2009-11-27 5:41 ` Ingo Molnar
2009-11-27 5:57 ` Tejun Heo
2009-11-27 6:20 ` Ingo Molnar
2009-11-27 6:31 ` Tejun Heo
2009-11-27 6:32 ` Tejun Heo
2009-11-28 9:51 ` Rusty Russell
2009-11-29 6:40 ` Ingo Molnar
2009-11-30 0:31 ` Rusty Russell [this message]
2009-11-25 13:24 ` [PATCH] x86: rename global percpu symbol dr7 to cpu_dr7 Tejun Heo
-- strict thread matches above, loose matches on Subject: below --
2009-11-12 6:45 linux-next: percpu tree build warning Stephen Rothwell
2009-11-12 15:16 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200911301101.59416.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.au \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).