On 04/22, Andrew Morton wrote:
quoted text
>
> > On Tue, 22 Apr 2008 13:09:21 +0400 Oleg Nesterov <oleg@tv-sign.ru> wrote:
> > On 04/21, Paul E. McKenney wrote:
> > >
> > > 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.

OK, will do, but....

quoted text
> 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.

we can make

	static inline void __deprecated nop_for_hlist_for_each_entry(void) {}

and insert it into the old macro's body

quoted text
> 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.

Ah. But this _is_ the problem. There is no a good name for hlist_for_each_entry()
except of course hlist_for_each_entry.

Well. I'll use hnode_for_each_entry_xxx(), but please let me know if you
change your mind ;)

Oleg.

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/