lkml.org 
[lkml]   [2010]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Revert 2fbd07a5f so machines with BSPs phsyical apic id != 0 can boot


On Mon, 11 Jan 2010, Suresh Siddha wrote:
>
> Linus, We are in -rc3 and thought we have few days atleast to sort it
> out and post the correct fix to the problem, rather than do a quick
> revert (as we know that the current code is not fundamentally broken).

You seem to think that -rc3 is "early". It's not.

Also, you seem to dismiss the fact that the commit has been reported to
break real machines, and then you try to blame the MACHINE instead of
blaming the commit.

That makes me irritated. I don't understand why it's so hard for people to
see that if there is a problem IT NEEDS TO BE FIXED.

The default action should not be "let's keep the problem and then try to
figure it out". No, the default action is "let's FIX the problem first!"

Once the problem is fixed, you have as much time as you want to try to
figure out why it happened in the first time. But we do _not_ just keep a
broken kernel around because you don't know what is broken.

> But if you want to revert, I have appended a patch to revert this, which
> has the correct subject, description etc atleast. I can work with Ananth
> and re-submit this for the next release.

Quite frankly, I hope the "re-submit" is not actually that. There's no
point in submitting something like this again. I still think that the
whole "let's have different code-paths for Intel and AMD" thing is just
plain crazy. There's no reason to do this.

For example, quite apart from the actual problem report, your patch causes
the x86-64 code to simply become UGLIER AND LESS MAINTAINABLE. That whole
intel-vs-amd issue is total black magic, with no comments and no reason.

So no. I'm not going to take a resubmission.

Linus


\
 
 \ /
  Last update: 2010-01-12 01:51    [W:1.418 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site