[PATCH] Add list_for_each_rcu to features-removal list

[PATCH] Add list_for_each_rcu to features-removal list

[Paul E. McKenney]

Hello!

The list_for_each_entry_rcu() primitive should be used instead of
list_for_each_rcu(), as the former is easier to use and provides
better type safety.  This patch therefore adds list_for_each_rcu()
to the Documentation/feature-removal-schedule.txt file (for mid-2008)
and marks its comment header deprecated.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---

 Documentation/feature-removal-schedule.txt |   10 ++++++++++
 include/linux/list.h                       |    5 ++++-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff -urpNa -X dontdiff linux-2.6.24/Documentation/feature-removal-schedule.txt linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt
--- linux-2.6.24/Documentation/feature-removal-schedule.txt	2008-01-24 14:58:37.000000000 -0800
+++ linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt	2008-01-28 04:00:49.000000000 -0800
@@ -333,3 +333,13 @@ Why:	This driver has been marked obsolet
 Who:	Stephen Hemminger <shemminger@linux-foundation.org>
 
 ---------------------------
+
+What:	list_for_each_rcu() primitive
+When:	July 2008
+Files:	include/linux/list.h
+Why:	The list_for_each_entry_rcu() primitive should be used instead,
+	as it is less error-prone and provides better type safety.
+Who:	Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+
+---------------------------
+
diff -urpNa -X dontdiff linux-2.6.24/include/linux/list.h linux-2.6.24-dep-lfeRCU/include/linux/list.h
--- linux-2.6.24/include/linux/list.h	2008-01-24 14:58:37.000000000 -0800
+++ linux-2.6.24-dep-lfeRCU/include/linux/list.h	2008-01-28 04:06:52.000000000 -0800
@@ -622,13 +622,16 @@ static inline void list_splice_init_rcu(
 	     pos = n, n = list_entry(n->member.prev, typeof(*n), member))
 
 /**
- * list_for_each_rcu	-	iterate over an rcu-protected list
+ * list_for_each_rcu - iterate over an rcu-protected list: DEPRECATED
  * @pos:	the &struct list_head to use as a loop cursor.
  * @head:	the head for your list.
  *
  * This list-traversal primitive may safely run concurrently with
  * the _rcu list-mutation primitives such as list_add_rcu()
  * as long as the traversal is guarded by rcu_read_lock().
+ *
+ * DEPRECATED: please use list_for_each_entry_rcu() instead: it is
+ * easier to use and also provides better type safety.
  */
 #define list_for_each_rcu(pos, head) \
 	for (pos = (head)->next; \

Re: [PATCH] Add list_for_each_rcu to features-removal list

[Adrian Bunk]

On Mon, Jan 28, 2008 at 04:25:00AM -0800, Paul E. McKenney wrote:
> Hello!
> 
> The list_for_each_entry_rcu() primitive should be used instead of
> list_for_each_rcu(), as the former is easier to use and provides
> better type safety.  This patch therefore adds list_for_each_rcu()
> to the Documentation/feature-removal-schedule.txt file (for mid-2008)
> and marks its comment header deprecated.
> 
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
> 
>  Documentation/feature-removal-schedule.txt |   10 ++++++++++
>  include/linux/list.h                       |    5 ++++-
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff -urpNa -X dontdiff linux-2.6.24/Documentation/feature-removal-schedule.txt linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt
> --- linux-2.6.24/Documentation/feature-removal-schedule.txt	2008-01-24 14:58:37.000000000 -0800
> +++ linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt	2008-01-28 04:00:49.000000000 -0800
> @@ -333,3 +333,13 @@ Why:	This driver has been marked obsolet
>  Who:	Stephen Hemminger <shemminger@linux-foundation.org>
>  
>  ---------------------------
> +
> +What:	list_for_each_rcu() primitive
> +When:	July 2008
> +Files:	include/linux/list.h
> +Why:	The list_for_each_entry_rcu() primitive should be used instead,
> +	as it is less error-prone and provides better type safety.
> +Who:	Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>...

Declaring something as deprecated doesn't automatically convert the 
in-kernel users.

And once there are no in-kernel users left you can kill it immediately.

The only working way for getting rid of list_for_each_rcu() is:
- send patches for all in-kernel usages to the maintainers of the code
  in question now
- once all of these patches have entered Linus' tree (which might not
  be before the 2.6.26 merge window) you can remove list_for_each_rcu()

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH] Add list_for_each_rcu to features-removal list

[Paul E. McKenney]

On Sat, Feb 16, 2008 at 10:47:23AM +0200, Adrian Bunk wrote:
> On Mon, Jan 28, 2008 at 04:25:00AM -0800, Paul E. McKenney wrote:
> > Hello!
> > 
> > The list_for_each_entry_rcu() primitive should be used instead of
> > list_for_each_rcu(), as the former is easier to use and provides
> > better type safety.  This patch therefore adds list_for_each_rcu()
> > to the Documentation/feature-removal-schedule.txt file (for mid-2008)
> > and marks its comment header deprecated.
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > 
> >  Documentation/feature-removal-schedule.txt |   10 ++++++++++
> >  include/linux/list.h                       |    5 ++++-
> >  2 files changed, 14 insertions(+), 1 deletion(-)
> > 
> > diff -urpNa -X dontdiff linux-2.6.24/Documentation/feature-removal-schedule.txt linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt
> > --- linux-2.6.24/Documentation/feature-removal-schedule.txt	2008-01-24 14:58:37.000000000 -0800
> > +++ linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt	2008-01-28 04:00:49.000000000 -0800
> > @@ -333,3 +333,13 @@ Why:	This driver has been marked obsolet
> >  Who:	Stephen Hemminger <shemminger@linux-foundation.org>
> >  
> >  ---------------------------
> > +
> > +What:	list_for_each_rcu() primitive
> > +When:	July 2008
> > +Files:	include/linux/list.h
> > +Why:	The list_for_each_entry_rcu() primitive should be used instead,
> > +	as it is less error-prone and provides better type safety.
> > +Who:	Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >...
> 
> Declaring something as deprecated doesn't automatically convert the 
> in-kernel users.

Understood.

> And once there are no in-kernel users left you can kill it immediately.

Hmmm...  What is the purpose of Documentation/feature-removal-schedule.txt
in that case?

> The only working way for getting rid of list_for_each_rcu() is:
> - send patches for all in-kernel usages to the maintainers of the code
>   in question now

That has happened at least once.

> - once all of these patches have entered Linus' tree (which might not
>   be before the 2.6.26 merge window) you can remove list_for_each_rcu()

So your approach would be to mark the macro obsolete to prevent additional
uses in the meantime?

							Thanx, Paul

Re: [PATCH] Add list_for_each_rcu to features-removal list

[Adrian Bunk]

On Sat, Feb 16, 2008 at 08:19:58AM -0800, Paul E. McKenney wrote:
> On Sat, Feb 16, 2008 at 10:47:23AM +0200, Adrian Bunk wrote:
> > On Mon, Jan 28, 2008 at 04:25:00AM -0800, Paul E. McKenney wrote:
> > > Hello!
> > > 
> > > The list_for_each_entry_rcu() primitive should be used instead of
> > > list_for_each_rcu(), as the former is easier to use and provides
> > > better type safety.  This patch therefore adds list_for_each_rcu()
> > > to the Documentation/feature-removal-schedule.txt file (for mid-2008)
> > > and marks its comment header deprecated.
> > > 
> > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > ---
> > > 
> > >  Documentation/feature-removal-schedule.txt |   10 ++++++++++
> > >  include/linux/list.h                       |    5 ++++-
> > >  2 files changed, 14 insertions(+), 1 deletion(-)
> > > 
> > > diff -urpNa -X dontdiff linux-2.6.24/Documentation/feature-removal-schedule.txt linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt
> > > --- linux-2.6.24/Documentation/feature-removal-schedule.txt	2008-01-24 14:58:37.000000000 -0800
> > > +++ linux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txt	2008-01-28 04:00:49.000000000 -0800
> > > @@ -333,3 +333,13 @@ Why:	This driver has been marked obsolet
> > >  Who:	Stephen Hemminger <shemminger@linux-foundation.org>
> > >  
> > >  ---------------------------
> > > +
> > > +What:	list_for_each_rcu() primitive
> > > +When:	July 2008
> > > +Files:	include/linux/list.h
> > > +Why:	The list_for_each_entry_rcu() primitive should be used instead,
> > > +	as it is less error-prone and provides better type safety.
> > > +Who:	Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > >...
> > 
> > Declaring something as deprecated doesn't automatically convert the 
> > in-kernel users.
> 
> Understood.
> 
> > And once there are no in-kernel users left you can kill it immediately.
> 
> Hmmm...  What is the purpose of Documentation/feature-removal-schedule.txt
> in that case?

I don't see any reason for not userspace visible things to be listed in
feature-removal-schedule.txt (with module names counted as being 
userspace visible) - they can be removed as soon as the last in-kernel 
user is gone.

> > The only working way for getting rid of list_for_each_rcu() is:
> > - send patches for all in-kernel usages to the maintainers of the code
> >   in question now
> 
> That has happened at least once.

Resend the patches (with a Cc to linux-kernel) until all of them got 
picked up...

> > - once all of these patches have entered Linus' tree (which might not
> >   be before the 2.6.26 merge window) you can remove list_for_each_rcu()
> 
> So your approach would be to mark the macro obsolete to prevent additional
> uses in the meantime?

That can't harm.

But realistically, the only way to prevent additional uses is to 
completely remove it...

> 							Thanx, Paul

cu
Adrian

-- 

  An architecture specific patch that breaks the one architecture it 
  touches at the first file being compiled is even for kernel standards 
  unusually bad...
                                Me about a recent commit in Linus' tree