[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120423165128.GA22364@phenom.dumpdata.com>
Date: Mon, 23 Apr 2012 12:51:28 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: "Luck, Tony" <tony.luck@...el.com>
Cc: Borislav Petkov <bp@...64.org>,
"Liu, Jinsong" <jinsong.liu@...el.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
On Mon, Apr 23, 2012 at 04:17:14PM +0000, Luck, Tony wrote:
> > This driver is _not_ doing a strict bit-by-bit copy of 'struct mcinfo'
> > to 'struct mce'. It is plucking the right bits and setting them in
> > 'struct mce'.
>
> That isn't any worse that what we currently have ... but what we currently
> have is ugly, and doing more ugly things just because we did them before
> generally isn't a winning argument on the mailing lists.
Heh.
Until about an hour ago I did not know that what is there is considered
'ugly' and you guys had thoughts of how to make it nicer. That is good.
And the driver isn't set in stone by only using those function - it can
change.
I am not sure if I have stated, but providing this driver in my mind
is an implicit contract that I, as the sub-maintainer, will keep it
in lock-step with mce.h cleanups. That is after all, the job of a
(sub)-maintainer.
--
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