"obsolete" versus "deprecated", and a new config option?

"obsolete" versus "deprecated", and a new config option?

[Robert P. J. Day]

  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

Re: "obsolete" versus "deprecated", and a new config option?

[Bill Davidsen]

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 <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: "obsolete" versus "deprecated", and a new config option?

[Robert P. J. Day]

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

Re: "obsolete" versus "deprecated", and a new config option?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

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?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: "obsolete" versus "deprecated", and a new config option?

[Robert P. J. Day]

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

Re: "obsolete" versus "deprecated", and a new config option?

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 350 bytes --]

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...

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: "obsolete" versus "deprecated", and a new config option?

[Robert P. J. Day]

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

Re: "obsolete" versus "deprecated", and a new config option?

[H. Peter Anvin]

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