linux-kernel - Re: [PATCH 0.01/1] hlist_for_each_entry

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]

Message-Id: <20080422064030.82b37fd9.akpm@linux-foundation.org>
Date:	Tue, 22 Apr 2008 06:40:30 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	paulmck@...ux.vnet.ibm.com, hch@....de, davem@...emloft.net,
	peterz@...radead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0.01/1] hlist_for_each_entry_xxx: kill the "pos"
 argument

> On Tue, 22 Apr 2008 13:09:21 +0400 Oleg Nesterov <oleg@...sign.ru> wrote:
> On 04/21, Paul E. McKenney wrote:
> >
> > On Mon, Apr 21, 2008 at 07:14:43PM +0400, Oleg Nesterov wrote:
> > > (The actual patch is huge, 116K, I'll send it offline. This email contains
> > >  the chunk for list.h only).
> > > 
> > > COMPILE TESTED ONLY (make allyesconfig).
> > > 
> > > All hlist_for_each_entry_xxx() macros require the "pos" argument, which is not
> > > actually needed and can be removed. See the changes in include/linux/list.h
> > > (note that hlist_for_each_entry_safe() now does prefetch() too).
> > 
> > Might it be better to do this in two
> > phases to allow these patches to be applied incrementally?
> > 
> > 1.	Change all to "obsolete" __hlist_for_each_entry_xxx().
> > 
> > 2.	Incrementally change to hlist_for_each_entry_xxx(), removing
> > 	the extra variable where possible.
> 
> Yes sure. Actually this was my initial plan.
> 
> Andrew, which way do you prefer?

Neither ;)

The smoothest transition would come by adding new macros with new names,
then migrating all callers over then removing the old macros.

Preferably after leaving the old, unused macros in place for a kernel
cycle, but there's not much value in that unless we can make them emil
warnings when used, which isn't completely trivial.

Plus there is no sensible new name which we can use.  Maybe you can think
of one, in which case that'd be a nice way to go.

> and should I wait for -rc1?

I wouldn't consider a change like this before -rc1.
--
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/