Next to EXPERIMENTAL, add two new kernel config categories of
DEPRECATED and OBSOLETE.
Signed-off-by: Robert P. J. Day <[email protected]>
---
speak now or forever ... too late.
diff --git a/init/Kconfig b/init/Kconfig
index a3f83e2..433dd30 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,26 @@ 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"
+ default y
+ ---help---
+ Code that is 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"
+ default n
+ ---help---
+ Code that is tagged as "obsolete" is officially no longer supported
+ and shouldn't play a part in any normal build, but those features
+ might still be available if you absolutely need access to them.
+
+ You are *strongly* discouraged from continuing to depend on
+ obsolete code on an ongoing, long-term basis.
+
config BROKEN
bool
Robert P. J. Day wrote:
> Next to EXPERIMENTAL, add two new kernel config categories of
> DEPRECATED and OBSOLETE.
What about adding some printks when DEPRECATED and OBSOLETE are
set ? like in print_tainted() for example.
C.
On Thu, 18 Jan 2007, Cedric Le Goater wrote:
> Robert P. J. Day wrote:
> > Next to EXPERIMENTAL, add two new kernel config categories of
> > DEPRECATED and OBSOLETE.
>
> What about adding some printks when DEPRECATED and OBSOLETE are set
> ? like in print_tainted() for example.
i preferred to introduce this as a non-intrusive change, which didn't
*require* any change to actual source code or header files. note that
you can add these two new categories (and any other categories you
can dream up) without changing *anything* else about the build
process. and once those two categories are in the init/Kconfig file,
subsystem maintainers can, on their own time, make the appropriate
changes to their subsystems. it's all perfectly voluntary.
also, code that's deprecated can still be tagged with
"__attribute__((deprecated))" in the source code.
rday
>> Next to EXPERIMENTAL, add two new kernel config categories of
>> DEPRECATED and OBSOLETE.
>
>What about adding some printks when DEPRECATED and OBSOLETE are
>set ? like in print_tainted() for example.
Uhm no. I don't want a load of messages just because one of these
options is active. I'd much rather prefer that when loading a _specific
module_ depends on DEPRECATED/OBSOLETE, a message is printed. But that's
an extra which I doubt it is worth modifying the kernel module structure
for.
-`J'
--