[<prev] [next>] [day] [month] [year] [list]
Message-ID: <fea02893-f940-4e12-9136-2953c7313544@email.android.com>
Date: Fri, 22 Jan 2010 18:34:53 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>
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,
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
Makes sense. Will do.
"Linus Torvalds" <torvalds@...ux-foundation.org> wrote:
>
>
>On Fri, 22 Jan 2010, Andrew Morton wrote:
>>
>> 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.
>
>Another way of looking at is "we know it's been broken for six months, and
>clearly nobody really ever enabled it in any distro, and even getting a
>bug report on it took forever. So why keep it around at all"?
>
>So I'd personally rather just remove it outright than deprecate it or even
>try to fix it. Since clearly absolutely nobody depends on it.
>
>The usual reason for deprecating a feature is to give people time to move
>away from it, but since clearly nobody uses it...
>
> Linus
--
Sent from my mobile phone, pardon any lack of formatting.
Powered by blists - more mailing lists