[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120423170327.GC22364@phenom.dumpdata.com>
Date: Mon, 23 Apr 2012 13:03:27 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: "Luck, Tony" <tony.luck@...el.com>,
"Liu, Jinsong" <jinsong.liu@...el.com>,
"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
"x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Borislav Petkov <bp@...64.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...nel.org>,
"linux-edac@...r.kernel.org" <linux-edac@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH 1/3] Add mcelog support for xen platform
On Mon, Apr 23, 2012 at 09:17:28AM -0700, H. Peter Anvin wrote:
> On 04/23/2012 08:27 AM, Luck, Tony wrote:
> >> Because, if you'd hooked into it, just imagine one fine day, when we
> >> remove mcelog support, what screaming the xen people will be doing when
> >> mcelog doesn't work anymore.
> >
> > Agreed. Even before we get to deleting mcelog, "struct mce" can change (new
> > fields could be added) ... and you don't want to have your hypervisor to
> > have to know which version of Linux it is talking to.
>
> This is a great example on the fundamental problem with Xen, or rather
> the approach that Xen has taken of grabbing random kernel internals and
> claiming them as APIs (or, in some cases even as ABIs.) A lot of these
I am _not_ claiming that. If I left you with that impression from my
responses - my fault for not getting my point across (the sleep deprevation
is probably not helping either).
I am _not_ stating that the usage of 'mce_log' or 'struct mce' MUST
remain the same from now on. No. I am saying that the driver will be
changed lock-step as Tony and Boris see fit in changing the functions.
And currently the way the existing MCE drivers do this - is by using
mce_log. This driver does is too - since the in-tree drivers do it this way.
When they change to use a different mechanism - this driver will as well.
> have had problems that are now very nearly unfixable, and that has
> seriously stalled out the ability of evolve the Linux kernel in some
> areas. Note that the cost of this is borne by the development
> community, not by the Xen maintainers.
The ones I know that you are unhappy about are the MMU paravirt interfaces
and I did mention to you that once some prototype work is done and
it showed success, I will work on removing said support.
Why don't you send me your unhappy list so that is on my radar as well please?
>
> -hpa
>
> --
> H. Peter Anvin, Intel Open Source Technology Center
> I work for Intel. I don't speak on their behalf.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@...ts.xen.org
> http://lists.xen.org/xen-devel
--
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