Prev: ftrace syscalls: Allow arch specific syscall symbol matching
Next: lmb: Move __alloc_memory_core_early() to nobootmem.c
From: Yinghai on 17 May 2010 02:20
On 05/16/2010 05:39 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2010-05-15 at 09:32 +0200, Ingo Molnar wrote:
>>
>> Btw., it would be nice to ready the LMB core bits for
>> upstream for 2.6.35 if there's agreement about them -
>> that will make the subsequent x86 patches much easier
>> to merge.
>
> Well, 2.6.34 was released already. I think it's a bit premature. We need
> to fix a few more things (the result codes for example) and do more
> testing to ensure we didn't break other archs.
>
so looks like your change will hit 2.6.35, and my x86 changes will hit 2.6.36?

that is too long.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 17 May 2010 02:50
On 05/16/2010 11:11 PM, Yinghai wrote:
>
> so looks like your change will hit 2.6.35, and my x86 changes will hit 2.6.36?
>
> that is too long.
>

Too long for what?

-hpa

--
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(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Benjamin Herrenschmidt on 17 May 2010 03:30
On Sun, 2010-05-16 at 23:11 -0700, Yinghai wrote:
> so looks like your change will hit 2.6.35, and my x86 changes will hit
> 2.6.36?
>
> that is too long.

No. Both will hit 2.6.36. It's way too late to queue up such changes for
the 2.6.35 merge window which has already opened.

Why would it be "too long" ? I keep asking what the heck is going on
with having a time bomb on those patches and yet have to get a
satisfactory answer.

Cheers,
Ben.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai on 17 May 2010 13:30
On 05/17/2010 12:24 AM, Benjamin Herrenschmidt wrote:
> On Sun, 2010-05-16 at 23:11 -0700, Yinghai wrote:
>> so looks like your change will hit 2.6.35, and my x86 changes will hit
>> 2.6.36?
>>
>> that is too long.
>
> No. Both will hit 2.6.36. It's way too late to queue up such changes for
> the 2.6.35 merge window which has already opened.

i have feeling that your new LMB code will hit 2.6.36. and
x86 patches that is using to lmb will hit 2.6.37.

otherwise it will make more merge conflicts between tip and lmb.
unless put your lmb change to tip?


>
> Why would it be "too long" ? I keep asking what the heck is going on
> with having a time bomb on those patches and yet have to get a
> satisfactory answer.

why are you thinking that there is time bomb in the patches?
I even provide the option to use x86 own low to high allocation.
really don't know where is the time bomb.

my -v14 patches only touch several lines your core lmb code, and have near 0 affect
to original lmb users.

YH
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 17 May 2010 15:10
On 05/17/2010 10:18 AM, Yinghai wrote:
>>
>> No. Both will hit 2.6.36. It's way too late to queue up such changes for
>> the 2.6.35 merge window which has already opened.
>
> i have feeling that your new LMB code will hit 2.6.36. and
> x86 patches that is using to lmb will hit 2.6.37.
>
> otherwise it will make more merge conflicts between tip and lmb.
> unless put your lmb change to tip?
>

We can arrange for some way of dealing with this problem... this is not
an issue.

>> Why would it be "too long" ? I keep asking what the heck is going on
>> with having a time bomb on those patches and yet have to get a
>> satisfactory answer.
>
> why are you thinking that there is time bomb in the patches?

You're the one that keeps saying "that is too long", but without
motivating the hurry.

-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: ftrace syscalls: Allow arch specific syscall symbol matching
Next: lmb: Move __alloc_memory_core_early() to nobootmem.c