[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20100122165356.55cf88aa.akpm@linux-foundation.org>
Date: Fri, 22 Jan 2010 16:53:56 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: "Rafael J. Wysocki" <rjw@...k.pl>,
Ozan Çağlayan <ozan@...dus.org.tr>,
Yinghai Lu <yinghai@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
mingo@...e.hu, a.p.zijlstra@...llo.nl, stable@...nel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jaswinder Singh Rajput <jaswinder@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: RFC: deprecate CONFIG_X86_CPU_DEBUG and schedule it for rapid
removal
On Sun, 17 Jan 2010 17:26:53 -0800
"H. Peter Anvin" <hpa@...or.com> wrote:
> CONFIG_X86_CPU_DEBUG really seems to be causing more problems than it
> ever solved. This is an RFC for immediately deprecating it, and
> schedule it for removal in the 2.6.34 cycle.
>
> If this was a high value feature, it would be different -- but it's not
> even close.
>
> Posting this as an RFC just on the offchance someone actually depends on
> this.
>
We know that enabling this feature will cause some machines to hang,
and that this problem has existed for six months.
Would it not be better to fix that problem (perhaps just with the
revert) so that 2.6.33, 2.6.32.x and earlier can be fixed? Then we can
nuke the feature in 2.6.34.
Alternatively, we can nuke the feature from 2.6.33 and 2.6.32.x and
earlier right now. Where "nuke" might mean "make it difficult to
enable".
Whatever. Bottom line is that it'd be nice to do something to fix up
2.6.33 and earlier.
--
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