[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20101027082537.GA23945@elte.hu>
Date: Wed, 27 Oct 2010 10:25:37 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Andi Kleen <andi@...stfloor.org>
Cc: Huang Ying <ying.huang@...el.com>, Len Brown <lenb@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Borislav Petkov <petkovbb@...glemail.com>,
Thomas Gleixner <tglx@...utronix.de>,
"H. Peter Anvin" <hpa@...or.com>, Don Zickus <dzickus@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [NAK] Re: [PATCH -v2 9/9] ACPI, APEI, Generic Hardware Error
Source POLL/IRQ/NMI notification type support
Btw., just for the record. Two days ago you started getting personal:
* Andi Kleen <andi@...stfloor.org> wrote:
> That's not really the old Ingo I used to know.
But when i (again) outlayed all the technical reasons for the NAK, you did not
answer. You also did not answer Thomas's technical mail either.
I've seen this behavior many times from you: when the technical argument goes
against you, when many people are telling you that you are mostly wrong, you do not
concede, you do not argue in support of your position, you simply ignore the
discussion from that point on and you pretend that the discussion does not exist
anymore.
Then a few weeks/months down the line this same pattern repeats: there's another
similar incident somewhere else, and i'm (or others) are forced to NAK the hard way.
You then claim it's unreasonable and you act as if the prior discussions did not
happen at all. Rinse and repeat. Most people dont remember so it even looks
plausible to the casual observer.
The thing is, upstream NAKs need to be addressed in good faith.
Again: i'm NAK-ing the use of the x86 NMI notifier chain in this fashion and i'm
NAK-ing the exports that this patch is adding to arch/x86/. It's not the proper
approach for the many reasons we outlined - debug facilities want to be organized in
the core, not spread out to vendor-specific fringes.
I wouldnt mind as much if this was a driver for hw few people care about - but this
looks like a useful piece of Intel hardware whose Linux support you are messing up
thoroughly by exporting an ABI in the worst possible way. We can and should do
better than this.
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/
Powered by blists - more mailing lists