"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





-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/