Re: [PATCH] x86/mm/srat_64.c: make node_possible_map include hotpluggablenode
From: H. Peter Anvin
Date: Fri Jan 22 2010 - 02:34:48 EST
On 01/21/2010 08:06 PM, Haicheng Li wrote:
> David Rientjes wrote:
>> You've already tested my patch that this thread was restarted with and it
>> works, so let's fix the bug. Then, later, you can rename
>> to no_mems_nodes, which I'd agree with. You may even try to seperate the
>> hotpluggable nodes out into their own nodemask, but I trust that the x86
>> maintainers will be looking for some rationale behind that other than "it
>> may one day be useful."
> David, you are misleading people to fix the BUG with a logically
> problematic patch. I don't want such fixing to possibly bother other
> people someday, please let's avoid it in review stage.
>> getting _very_ late in the 2.6.33 release cycle. Do you expect Ingo to
>> push your fix to Linus with the rationale that "maybe someday we'll use
>> this new nodemask even though it may be rc5 and nobody knows what we'd
>> ever use it for"? Is that appropriate for -stable candidates as well?
> Don't speak for any other people. Let maintainers themselves decide if
> my patch is ugly or acceptable. I don't want to argue with you anymore
> if you cannot find any true problem from my recent patch.
> Below is my updated patch (in fact, it's v2 for the patch I sent out for
> review in http://lkml.org/lkml/2010/1/15/9).
Okay... please calm down. I just read through this thread from the top,
and had missed the fact that it had gotten so tense.
I have to say I agree with David Rientjes that we need the minimal patch
for upstream and stable. If you need the additional bitmask in the
future it should be added later.
Haicheng, would you be willing to prepare a minimal patch so we can
close the issue in the release trees as quickly as possible?
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/