Add list_for_each_rcu to features-removal list
PATCH 1/1 Add list_for_each_rcu to features-removal list
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.
---
Documentation/feature-removal-schedule.txt | 10 ++++++++++ include/linux/list.h | 5 ++++- 2 files changed, 14 insertions(+), 1 deletion(-)
Documentation/feature-removal-schedule.txt +10 -0
@@ -333,3 +333,13 @@ Why: This driver has been marked obsolet Who: Stephen Hemminger <[email protected]> --------------------------- + +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 <[email protected]> + +--------------------------- +
include/linux/list.h +4 -1
@@ -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; \
Quoted 20 lines · Paul E. McKenney
Hello!
The
list_for_each_entry_rcu()primitive should be used instead oflist_for_each_rcu(), as the former is easier to use and provides better type safety. This patch therefore addslist_for_each_rcu()to theDocumentation/feature-removal-schedule.txtfile (for mid-2008) and marks its comment header deprecated.Signed-off-by Paul E. McKenney <[email protected]>---
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.txtlinux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txtDocumentation/feature-removal-schedule.txt +0
-0@@ -333,3 +333,13 @@ Why: This driver has been marked obsolet Who: Stephen Hemminger <[email protected]>
Documentation/feature-removal-schedule.txt Why: This driver has been marked obsolet · line 342
Quoted 10 lines
Documentation/feature-removal-schedule.txt +7
-0--------------------------- + +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 <[email protected]>
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
Signature · 4 lines
"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 SeedQuoted 22 lines · Adrian Bunk
Quoted 21 lines · Paul E. McKenney
Hello!
The
list_for_each_entry_rcu()primitive should be used instead oflist_for_each_rcu(), as the former is easier to use and provides better type safety. This patch therefore addslist_for_each_rcu()to theDocumentation/feature-removal-schedule.txtfile (for mid-2008) and marks its comment header deprecated.Signed-off-by Paul E. McKenney <[email protected]>---
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.txtlinux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txtDocumentation/feature-removal-schedule.txt +0
-0@@ -333,3 +333,13 @@ Why: This driver has been marked obsolet Who: Stephen Hemminger <[email protected]>
Quoted 12 lines
Documentation/feature-removal-schedule.txt Why: This driver has been marked obsolet · line 342
Quoted 9 lines
Documentation/feature-removal-schedule.txt +7
-0--------------------------- + +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 <[email protected]>Declaring something as deprecated doesn't automatically convert the in-kernel users.
Understood.
Quoted 1 line
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?
Quoted 3 lines
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.
Quoted 2 lines
- 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
Quoted 36 lines · Paul E. McKenney
Quoted 22 lines · Adrian Bunk
Quoted 21 lines · Paul E. McKenney
Hello!
The
list_for_each_entry_rcu()primitive should be used instead oflist_for_each_rcu(), as the former is easier to use and provides better type safety. This patch therefore addslist_for_each_rcu()to theDocumentation/feature-removal-schedule.txtfile (for mid-2008) and marks its comment header deprecated.Signed-off-by Paul E. McKenney <[email protected]>---
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.txtlinux-2.6.24-dep-lfeRCU/Documentation/feature-removal-schedule.txtDocumentation/feature-removal-schedule.txt +0
-0@@ -333,3 +333,13 @@ Why: This driver has been marked obsolet Who: Stephen Hemminger <[email protected]>Quoted 12 lines
Documentation/feature-removal-schedule.txt Why: This driver has been marked obsolet · line 342
Quoted 9 lines
Documentation/feature-removal-schedule.txt +7
-0--------------------------- + +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 <[email protected]>Declaring something as deprecated doesn't automatically convert the in-kernel users.
Quoted 6 lines
Understood.
Quoted 1 line
And once there are no in-kernel users left you can kill it immediately.
Hmmm... What is the purpose of
Documentation/feature-removal-schedule.txtin 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.
Quoted 5 lines
Quoted 3 lines
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 nowThat has happened at least once.
Resend the patches (with a Cc to linux-kernel) until all of them got picked up...
Quoted 5 lines
Quoted 2 lines
- 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...
Quoted 1 line
Thanx, Paul
cu
Adrian
Signature · 4 lines
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