Robert Day proposed a couple of new kernel code maturity configuration options for tagging code as either "deprecated" or "obsolete". He referenced earlier confusion around the attempt to remove devfs [story] in which it wasn't clear on the current state and future plans for the code. He explained, "using deprecated code is still technically fine, but using obsolete code should be something that raises a red flag of some kind." Aside from a little confusion between the differences in definition between these two words, general feedback was positive. H. Peter Anvin supported the patch, "if nothing else, it gives some middle-of-the-roadness to the continual 'to remove or not to remove' debate." Robert also noted that the "deprecated" flag would be a useful sanity check when building a kernel, "this would seem to be a quick and dirty way to prune anything that is *supposed* to be obsolete from the build, to make sure you're not picking up dead code by accident." The patch includes definitions of these two states:
"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.
"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."
From: "Robert P. J. Day" [email blocked]
To: Linux kernel mailing list [email blocked]
Subject: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 11:51:27 -0500 (EST)
a couple random thoughts on the notion of obsolescence and
deprecation.
first, there are places in the kernel (primarily Kconfig files) and
the documentation that unnecessarily conflate these two properties.
as a simple example, consider drivers/pcmcia/Kconfig:
==========================================================
config PCMCIA_IOCTL
bool "PCMCIA control ioctl (obsolete)"
depends on PCMCIA
default y
help
If you say Y here, the deprecated ioctl interface to the PCMCIA
subsystem will be built. It is needed by cardmgr and cardctl
(pcmcia-cs) to function properly.
You should use the new pcmciautils package instead (see
<file:Documentation/Changes> for location and details).
If unsure, say Y.
==========================================================
so is that ioctl obsolete or deprecated? those aren't the same
things, a good distinction being drawn here by someone discussing
devfs:
http://kerneltrap.org/node/1893
"Devfs is deprecated. This means it's still available but you should
consider moving to other options when available. Obsolete means it
shouldn't be used. Some 2.6 docs have confused these two terms WRT
devfs."
yes, and that confusion continues to this day, when a single feature
is described as both deprecated and obsolete. not good. (also, i'm
guessing that anything that's "obsolete" might deserve a default of
"n" rather than "y", but that's just me. :-)
in any event, what about introducing a new config variable,
OBSOLETE, under "Code maturity level options"? this would seem to be
a quick and dirty way to prune anything that is *supposed* to be
obsolete from the build, to make sure you're not picking up dead code
by accident.
i think it would be useful to be able to make that kind of
distinction since, as the devfs writer pointed out above, the point of
labelling something "obsolete" is not to *discourage* someone from
using a feature, it's to imply that they *shouldn't* be using that
feature. period. which suggests there should be an easy, one-step
way to enforce that absolutely in a build.
thoughts?
rday
From: Bill Davidsen [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 13:13:45 -0500
Robert P. J. Day wrote:
> a couple random thoughts on the notion of obsolescence and
> deprecation.
[...horrible example deleted...]
> so is that ioctl obsolete or deprecated? those aren't the same
> things, a good distinction being drawn here by someone discussing
> devfs:
>
> http://kerneltrap.org/node/1893
>
> "Devfs is deprecated. This means it's still available but you should
> consider moving to other options when available. Obsolete means it
> shouldn't be used. Some 2.6 docs have confused these two terms WRT
> devfs."
>
> yes, and that confusion continues to this day, when a single feature
> is described as both deprecated and obsolete. not good. (also, i'm
> guessing that anything that's "obsolete" might deserve a default of
> "n" rather than "y", but that's just me. :-)
Agree on that. I would hope "obsolete" means there's a newer way which
should provide the functionality (** help should say where that is **)
while depreciated should mean "we decided this was a bad solution" or
something like that.
>
> in any event, what about introducing a new config variable,
> OBSOLETE, under "Code maturity level options"? this would seem to be
> a quick and dirty way to prune anything that is *supposed* to be
> obsolete from the build, to make sure you're not picking up dead code
> by accident.
If you're doing that, why not four variables, for incomplete,
experimental, obsolete and depreciated? Unfortunately doing any more
detailed nomenclature would be a LOT of work!
>
> i think it would be useful to be able to make that kind of
> distinction since, as the devfs writer pointed out above, the point of
> labelling something "obsolete" is not to *discourage* someone from
> using a feature, it's to imply that they *shouldn't* be using that
> feature. period. which suggests there should be an easy, one-step
> way to enforce that absolutely in a build.
>
> thoughts?
>
I think it's a good idea, but doing it right may be more work than the
benefit justifies.
--
bill davidsen [email blocked]
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
From: "Robert P. J. Day" [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 13:42:15 -0500 (EST)
On Wed, 17 Jan 2007, Bill Davidsen wrote:
> Robert P. J. Day wrote:
> > a couple random thoughts on the notion of obsolescence and
> > deprecation.
>
> [...horrible example deleted...]
>
> > so is that ioctl obsolete or deprecated? those aren't the same
> > things, a good distinction being drawn here by someone discussing
> > devfs:
> >
> > http://kerneltrap.org/node/1893
> >
> > "Devfs is deprecated. This means it's still available but you
> > should consider moving to other options when available. Obsolete
> > means it shouldn't be used. Some 2.6 docs have confused these two
> > terms WRT devfs."
> >
> > yes, and that confusion continues to this day, when a single
> > feature is described as both deprecated and obsolete. not good.
> > (also, i'm guessing that anything that's "obsolete" might deserve
> > a default of "n" rather than "y", but that's just me. :-)
>
> Agree on that. I would hope "obsolete" means there's a newer way
> which should provide the functionality (** help should say where
> that is **) while depreciated should mean "we decided this was a bad
> solution" or something like that.
in simpler terms, "deprecated" (note correct spelling :-) should mean
"it's still available and you can use it but you should seriously
think of moving up soon 'cuz this is going to disappear some day,"
while "obsolete" should mean, "it's dead, jim."
> > in any event, what about introducing a new config variable,
> > OBSOLETE, under "Code maturity level options"? this would seem to
> > be a quick and dirty way to prune anything that is *supposed* to
> > be obsolete from the build, to make sure you're not picking up
> > dead code by accident.
>
> If you're doing that, why not four variables, for incomplete,
> experimental, obsolete and depreciated? Unfortunately doing any more
> detailed nomenclature would be a LOT of work!
i wouldn't go that far. using deprecated code is still technically
fine, but using obsolete code should be something that raises a red
flag of some kind. i would just somehow mark the OBSOLETE stuff. in
fact, some kernel config options already do something like this, such
as in drivers/mtd/chips/Kconfig:
config MTD_OBSOLETE_CHIPS
depends on MTD
bool "Older (theoretically obsoleted now) drivers for non-CFI chips"
help
... yadda yadda yadda ...
config MTD_AMDSTD
tristate "AMD compatible flash chip support (non-CFI)"
depends on MTD && MTD_OBSOLETE_CHIPS && BROKEN
...
and there's plenty of places in the Kconfig files that label features
as obsolete. i just want the ability to switch all that stuff off
with one mouse click and see what happens.
rday
From: Valdis.Kletnieks [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 16:54:03 -0500
On Wed, 17 Jan 2007 11:51:27 EST, "Robert P. J. Day" said:
>
> in any event, what about introducing a new config variable,
> OBSOLETE, under "Code maturity level options"? this would seem to be
> a quick and dirty way to prune anything that is *supposed* to be
> obsolete from the build, to make sure you're not picking up dead code
> by accident.
>
> i think it would be useful to be able to make that kind of
> distinction since, as the devfs writer pointed out above, the point of
> labelling something "obsolete" is not to *discourage* someone from
> using a feature, it's to imply that they *shouldn't* be using that
> feature. period. which suggests there should be an easy, one-step
> way to enforce that absolutely in a build.
How much of the 'OBSOLETE' code should just be labelled 'BROKEN' instead?
From: "Robert P. J. Day" [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 17:04:20 -0500 (EST)
On Wed, 17 Jan 2007, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 17 Jan 2007 11:51:27 EST, "Robert P. J. Day" said:
> >
> > in any event, what about introducing a new config variable,
> > OBSOLETE, under "Code maturity level options"? this would seem to be
> > a quick and dirty way to prune anything that is *supposed* to be
> > obsolete from the build, to make sure you're not picking up dead code
> > by accident.
> >
> > i think it would be useful to be able to make that kind of
> > distinction since, as the devfs writer pointed out above, the point of
> > labelling something "obsolete" is not to *discourage* someone from
> > using a feature, it's to imply that they *shouldn't* be using that
> > feature. period. which suggests there should be an easy, one-step
> > way to enforce that absolutely in a build.
>
> How much of the 'OBSOLETE' code should just be labelled 'BROKEN'
> instead?
the stuff that's actually "broken." :-)
OBSOLETE is not (or at least *should not* be) equivalent to BROKEN.
"OBSOLETE" should denote code that, while it is no longer supported
and has a viable replacement, may very well still work. and it may or
may not be slated for removal some day. there may very well be
reasons to keep "obsolete" code in the kernel, for occasional backward
compatibility, but marking it as "obsolete" is a powerful indicator
that people should *really* try not to use it.
"BROKEN" code, OTOH, really should mean exactly that -- code that is
*known* to be broken. that would include old code that has suffered
bit rot, but it might also include *new* code that, while it's now
part of the kernel, someone discovers a major flaw in it and no one's
got around to fixing it yet. so even bleeding-edge code can
technically be "broken" until someone gets around to debugging it.
thoughts?
rday
From: Valdis.Kletnieks
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 17:54:13 -0500
On Wed, 17 Jan 2007 17:04:20 EST, "Robert P. J. Day" said:
> > How much of the 'OBSOLETE' code should just be labelled 'BROKEN'
> > instead?
>
> the stuff that's actually "broken." :-)
Right - the question is how much code qualifies as either/both, and which
we should use when we encounter the random driver that's both obsolete
*and* broken...
From: "Robert P. J. Day" [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 17:51:55 -0500 (EST)
On Wed, 17 Jan 2007, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 17 Jan 2007 17:04:20 EST, "Robert P. J. Day" said:
>
> > > How much of the 'OBSOLETE' code should just be labelled 'BROKEN'
> > > instead?
> >
> > the stuff that's actually "broken." :-)
>
> Right - the question is how much code qualifies as either/both, and
> which we should use when we encounter the random driver that's both
> obsolete *and* broken...
that's entirely a judgment call on the part of the code's maintainer.
if something is both obsolete and broken, then make it depend on
*both* OBSOLETE and BROKEN if you want. no big deal.
rday
From: "H. Peter Anvin" [email blocked]
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Thu, 18 Jan 2007 13:37:47 -0800
Robert P. J. Day wrote:
>
> that's entirely a judgment call on the part of the code's maintainer.
> if something is both obsolete and broken, then make it depend on
> *both* OBSOLETE and BROKEN if you want. no big deal.
>
Yup.
OBSOLETE = might be broken, no one is planning to maintain it.
BROKEN = known to be broken.
They're by and large orthogonal.
-hpa
From: "Robert P. J. Day" [email blocked]
Subject: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE.
Date: Wed, 17 Jan 2007 16:21:19 -0500 (EST)
To go along with the EXPERIMENTAL kernel config status, introduce
two new states: DEPRECATED and OBSOLETE.
Signed-off-by: Robert P. J. Day [email blocked]
---
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 features
+ might still be available if you absolutely need access to them.
+
+ It's *strongly* discouraged to continue to depend on obsolete code.
+
config BROKEN
bool
From: "H. Peter Anvin" [email blocked]
Subject: Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE.
Date: Wed, 17 Jan 2007 13:55:27 -0800
Robert P. J. Day wrote:
> To go along with the EXPERIMENTAL kernel config status, introduce
> two new states: DEPRECATED and OBSOLETE.
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
From: "Robert P. J. Day" [email blocked]
Subject: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
Date: Wed, 17 Jan 2007 17:48:33 -0500 (EST)
Next to EXPERIMENTAL, add two new kernel config categories of
DEPRECATED and OBSOLETE.
Signed-off-by: Robert P. J. Day [email blocked]
---
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
