Messages in this thread | | | Date | Sat, 16 Feb 2008 18:39:39 +0200 | From | Adrian Bunk <> | Subject | Re: [PATCH] Add list_for_each_rcu to features-removal list |
| |
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
| |