LKML Archive on
help / color / mirror / Atom feed
From: "Robert P. J. Day" <>
To: Bill Davidsen <>
Cc: Linux Kernel mailing List <>
Subject: Re: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 13:42:15 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701171333270.2800@CPE00045a9c397f-CM001225dbafb6> (raw)
In-Reply-To: <>

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:
> >
> >
> >
> > "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:

        depends on MTD
        bool "Older (theoretically obsoleted now) drivers for non-CFI chips"
          ... yadda yadda yadda ...

        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.


  reply	other threads:[~2007-01-17 18:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 16:51 Robert P. J. Day
2007-01-17 18:13 ` Bill Davidsen
2007-01-17 18:42   ` Robert P. J. Day [this message]
2007-01-17 21:54 ` Valdis.Kletnieks
2007-01-17 22:04   ` Robert P. J. Day
2007-01-17 22:54     ` Valdis.Kletnieks
2007-01-17 22:51       ` Robert P. J. Day
2007-01-18 21:37         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0701171333270.2800@CPE00045a9c397f-CM001225dbafb6 \ \ \ \
    --subject='Re: "obsolete" versus "deprecated", and a new config option?' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).