lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Nov 2012 17:59:47 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sasha Levin <sasha.levin@...cle.com>
Cc:	paulmck@...ux.vnet.ibm.com, dipankar@...ibm.com, mingo@...nel.org,
	hpa@...or.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, peter.senna@...il.com
Subject: Re: [RFC] hlist: drop the node parameter from iterators

On Thu, Nov 1, 2012 at 4:06 PM, Sasha Levin <sasha.levin@...cle.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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ