[PATCH] Add list_for_each_rcu to features-removal list
Paul E. McKenney
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 <pau...@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 <shemm...@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 <pau...@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; \
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Adrian Bunk
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
Paul E. McKenney
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
Adrian Bunk
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