Mailing List Archive

[PATCH] Add new categories of DEPRECATED and OBSOLETE.
Next to EXPERIMENTAL, add two new kernel config categories of
DEPRECATED and OBSOLETE.

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

---

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE. [ In reply to ]
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE. [ In reply to ]
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE. [ In reply to ]
>> 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'
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/