LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@mindspring.com>
To: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: "obsolete" versus "deprecated", and a new config option?
Date: Wed, 17 Jan 2007 11:51:27 -0500 (EST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0701171134440.1878@CPE00045a9c397f-CM001225dbafb6> (raw)


  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






             reply	other threads:[~2007-01-17 16:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-17 16:51 Robert P. J. Day [this message]
2007-01-17 18:13 ` Bill Davidsen
2007-01-17 18:42   ` Robert P. J. Day
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* 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.0701171134440.1878@CPE00045a9c397f-CM001225dbafb6 \
    --to=rpjday@mindspring.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: "obsolete" versus "deprecated", and a new config option?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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