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

[Linus Torvalds]

On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin <sasha.levin@xxxxxxxxxx> 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 extra parameter:
>
>         hlist_for_each_entry(tpos, pos, head, member)
>
> Why did they need an extra pos parameter? I'm not quite sure. Not only
> they don't really need it, it also prevents the iterator from looking
> exactly like the list iterator, which is unfortunate.
>
> [..]
>  170 files changed, 481 insertions(+), 879 deletions(-)
>
> Yes, beyond making hlist prettier, we also drop 400 lines. win-win?

So this has been discussed before, and one of the problems with this
is just the pain of maintenance. This tends to cause annoyances for
merging, but also for -stable backporting etc, because it just results
in a lot of noise.

Now, the hlist_for_each() case isn't used by quite as many sites as
some of the others helpers like this, so maybe the pain isn't horribly
bad, but in general I do tend to get nervous about "let's clean it up"
when it touches hundreds of files.

Your thing looks nice in that it has the coccinelle script (which
hopefully means that we really get them all), but just out of
interest, how different is the patch after running the script on both

 (a) my current -git head
 (b) linux-next

because differences (other than just line numbers) imply conflicts.
How many differences are we talking about? None? Two? Twenty?

(That said, right now linux-next is tiny. It might be more interesting
to look at the linux-3.5 vs linux-3.6 to get more of a feel for
differences between releases. Doing just the diff+grep thing, there's
quite a few changes around hlist_for_each_entry() uses)

                     Linus
--
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/