On Fri, Nov 2, 2012 at 1:33 PM, Sasha Levin wrote:
>
> Do you want the patch on top of your git head, or on top of -next?
So the thing is, there's no way I'm going to apply this kind of patch
anywhere *near* a merge window. With something like this, it needs to
get applied a few weeks after the
On 11/02/2012 04:16 PM, Linus Torvalds wrote:
> On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin wrote:
>>
>> Here are some stats:
>>
>> - Applying the patch from -next on top of your current git head
>> results in 3 conflicts.
>>
>> - Applying the patch from your current git head on top of v3.6
On Fri, Nov 2, 2012 at 9:16 PM, Linus Torvalds
wrote:
> On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin wrote:
>>
>> Here are some stats:
>>
>> - Applying the patch from -next on top of your current git head
>> results in 3 conflicts.
>>
>> - Applying the patch from your current git head on top of
On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin wrote:
>
> Here are some stats:
>
> - Applying the patch from -next on top of your current git head
> results in 3 conflicts.
>
> - Applying the patch from your current git head on top of v3.6 results
> in 18 conflicts.
>
> - Applying the patch from
On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin sasha.le...@oracle.com wrote:
Here are some stats:
- Applying the patch from -next on top of your current git head
results in 3 conflicts.
- Applying the patch from your current git head on top of v3.6 results
in 18 conflicts.
- Applying the
On Fri, Nov 2, 2012 at 9:16 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin sasha.le...@oracle.com wrote:
Here are some stats:
- Applying the patch from -next on top of your current git head
results in 3 conflicts.
- Applying the patch
On 11/02/2012 04:16 PM, Linus Torvalds wrote:
On Thu, Nov 1, 2012 at 7:26 PM, Sasha Levin sasha.le...@oracle.com wrote:
Here are some stats:
- Applying the patch from -next on top of your current git head
results in 3 conflicts.
- Applying the patch from your current git head on top of
On Fri, Nov 2, 2012 at 1:33 PM, Sasha Levin sasha.le...@oracle.com wrote:
Do you want the patch on top of your git head, or on top of -next?
So the thing is, there's no way I'm going to apply this kind of patch
anywhere *near* a merge window. With something like this, it needs to
get applied a
On 11/01/2012 08:59 PM, Linus Torvalds wrote:
> On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin wrote:
>> I'm not sure why, but the hlist for each entry iterators were conceived
>> differently from the list ones. While the list ones are nice and elegant:
>>
>> list_for_each_entry(pos, head,
On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin wrote:
> I'm not sure why, but the hlist for each entry iterators were conceived
> differently from the list ones. While the list ones are nice and elegant:
>
> list_for_each_entry(pos, head, member)
>
> The hlist ones were greedy and wanted an
I'm not sure why, but the hlist for each entry iterators were conceived
differently from the list ones. While the list ones are nice and elegant:
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos,
I'm not sure why, but the hlist for each entry iterators were conceived
differently from the list ones. While the list ones are nice and elegant:
list_for_each_entry(pos, head, member)
The hlist ones were greedy and wanted an extra parameter:
hlist_for_each_entry(tpos, pos,
On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin sasha.le...@oracle.com wrote:
I'm not sure why, but the hlist for each entry iterators were conceived
differently from the list ones. While the list ones are nice and elegant:
list_for_each_entry(pos, head, member)
The hlist ones were
On 11/01/2012 08:59 PM, Linus Torvalds wrote:
On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin sasha.le...@oracle.com wrote:
I'm not sure why, but the hlist for each entry iterators were conceived
differently from the list ones. While the list ones are nice and elegant:
14 matches
Mail list logo