To go along with the EXPERIMENTAL kernel config status, introduce
two new states:  DEPRECATED and OBSOLETE.

Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>

---

  just adding these config variables to init/Kconfig shouldn't affect
the current build status, but it will allow developers to start to
move over their portions of tree at their convenience.

  in particular, features that are truly obsolete should be tagged as
OBSOLETE, as opposed to EXPERIMENTAL.


diff --git a/init/Kconfig b/init/Kconfig
index a3f83e2..f861efd 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -29,9 +29,10 @@ config EXPERIMENTAL
 	  <file:Documentation/BUG-HUNTING>, and
 	  <file:Documentation/oops-tracing.txt> in the kernel source).

-	  This option will also make obsoleted drivers available. These are
-	  drivers that have been replaced by something else, and/or are
-	  scheduled to be removed in a future kernel release.
+	  At the moment, this option also makes obsolete drivers available,
+	  but such drivers really should be removed from the EXPERIMENTAL
+	  category and added to either DEPRECATED or OBSOLETE, depending
+	  on their status.

 	  Unless you intend to help test and develop a feature or driver that
 	  falls into this category, or you have a situation that requires
@@ -40,6 +41,23 @@ config EXPERIMENTAL
 	  you say Y here, you will be offered the choice of using features or
 	  drivers that are currently considered to be in the alpha-test phase.

+config DEPRECATED
+	bool "Prompt for deprecated code/drivers"
+	---help---
+	  Code that has tagged as "deprecated" is officially still available
+	  for use but will typically have already been scheduled for removal
+	  at some point, so it's in your best interests to start looking for
+	  an alternative.
+
+config OBSOLETE
+	bool "Prompt for obsolete code/drivers"
+	---help---
+	  Code that has tagged as "obsolete" is officially no longer supported
+	  and shouldn't play a part in any normal build, but those ...
[ message continues ]

I think this is a very good idea.  If nothing else, it gives some 
middle-of-the-roadness to the continual "to remove or not to remove" debate.

	-hpa
-

[ message continues ]

DEPRECATED should presumably default to Y; OBSOLETE to n.

	-hpa
-

[ message continues ]

crap, now i see what you were getting at -- i forgot to assign
defaults.  i'll resubmit, but i'll wait for anyone to suggest any
better help content if they have a better idea.

rday
-

[ message continues ]

Well... _maybe_ documentation/scheduled-removal.txt (or whatever it is 
called) could now be merged into the kconfig options and help text. Or 
maybe not, to keep it easy to track deprecated code.

Well, even if scheduled-removal.txt stays, you could submit a 2nd patch 
putting OBSOLETE and DEPRECATED tags to the Kconfig options listed in 
scheduled-removal.txt, so that kconfig+sched are in sync.


	-`J'
-- 
-

[ message continues ]

i'm assuming you mean "Documentation/feature-removal-schedule.txt".
that would *seem* to make sense, after only a few seconds of thought.
once config options are tagged with either DEPRECATED or OBSOLETE,
surely it wouldn't be hard to be able to pull out a list of those from
the source tree, based on their Kconfig dependencies.

but, again, that's getting ahead of ourselves.  certainly, it's
something that *could* be done at some point, but not knowing exactly
how one would do that doesn't stop anyone from adding those two config
settings *now*, just to get the process rolling.

let's not over-analyze this too much.

rday

p.s.  it might be worth perusing the feature removal file, to see what
features are still listed there even though they were scheduled to be
removed some time ago.  just a thought.
-

[ message continues ]

you presume correctly.

rday
-

[ message continues ]