Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Linus Torvalds
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Sasha Levin
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Peter Senna Tschudin
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Linus Torvalds
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Linus Torvalds
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Peter Senna Tschudin
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Sasha Levin
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-02 Thread Linus Torvalds
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Sasha Levin
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,

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Linus Torvalds
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

[RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Sasha Levin
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,

[RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Sasha Levin
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,

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Linus Torvalds
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

Re: [RFC] hlist: drop the node parameter from iterators

2012-11-01 Thread Sasha Levin
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: