From: "David Schwartz" <davids@webmaster.com>
To: "Linux-Kernel@Vger. Kernel. Org" <linux-kernel@vger.kernel.org>
Subject: RE: undeprecate raw driver.
Date: Mon, 14 May 2007 19:47:34 -0700 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKCENKDMAC.davids@webmaster.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0705140957370.12444@localhost.localdomain>
> On Mon, 14 May 2007, Bob Johnston wrote:
> > Alan Cox <alan <at> lxorguk.ukuu.org.uk> writes:
> >
> > > > Why not just use the terms:
> > > > * outdated - as a replacement for "deprecated".
> > >
> > > Because they don't actually mean the same thing ?
> >
> > "superseded" would probably be a better word, perhaps lacking the
> > negative connotations of "deprecated"
> except that you *want* the negative connotation associated with the
> word "deprecated." you don't just want to say something's been
> superseded. rather, you want to say that it's not only been
> superseded but that you really want people to *stop using it* and move
> up to the newer version; otherwise, there is no motivation to upgrade.
> i'm just baffled by the resistance to the word "deprecated" since it
> represents *exactly* the idea you want to get across here. its use
> in software projects is well-established. why are some people so put
> off by it?
Let me give this a big AOL-style "me too". Terms such as "deprecated" and
"obsolete" have been used by programmers for as long as I can remember, and
if you don't know exactly what they mean, you probably should just learn.
A feature is "deprecated" if there is some other feature or mechanism that
is considered superior to it in all cases. It may just be more efficient, it
may avoid potential pitfalls of the deprecated mechanism.
You should avoid using a deprecated feature in new code and should try to
remove use of it from old code. The classic example of a deprecated function
is 'gets'. Deprecated features are generally kept for compatability purposes
or because standards require them. A function deprecated on one platform may
be perfectly fine on another.
You might choose to use a deprecated feature for compatability purposes. It
is not urgent to hack use of deprecated features out of existing code.
(However, you should evaluate whether the reason for deprecation creates a
problem in your code, especially if it's a security issue.)
Deprecated features can reasonably be expected to continue to work as well
as they ever have. They should not be newly-broken. If a deprecated feature
is broken in a new version, that is a regression.
A feature is "obsolete" if it no longer serves any purpose. It may be so
broken that it is no longer even usable. It might still be technically
working but not have any actual case of any significance in which you might
want to use it. Linux's Sony CDU-535 driver is obsolete (a driver for an old
CDROM drive with a specialized ISA controller that transferred data at well
less than 1X and supports only a *very* slow PIO mode).
Obsolete features are generally scheduled for removal. They are usually not
removed just on the off chance that the removal might harm someone. It may
not even be possible to test them and the last time they were tested may
have been several major releases ago. One should generally not expect
obsolete features to work.
Something obsolete may conflict with never features. For example, a driver
that breaks with hotpluggable CPUs. One contemplating using an obsolete
feature in a new design should have a damn good reason and might possibly
need to have their head examined.
The raw driver *is* deprecated. It is *not* obsolete.
DS
next prev parent reply other threads:[~2007-05-15 2:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-13 16:32 undeprecate raw driver Dave Jones
2007-05-13 16:35 ` Jan Engelhardt
2007-05-13 16:43 ` Dave Jones
2007-05-13 16:46 ` Robert P. J. Day
2007-05-13 17:34 ` Bernd Eckenfels
2007-05-13 17:56 ` Robert P. J. Day
2007-05-13 20:06 ` Stefan Richter
2007-05-13 20:24 ` Robert P. J. Day
2007-05-13 21:40 ` Stefan Richter
2007-05-13 20:10 ` Stefan Richter
2007-05-13 21:49 ` Tilman Schmidt
2007-05-13 22:42 ` Stefan Richter
2007-05-13 23:01 ` Bob Johnston
2007-05-14 11:42 ` Alan Cox
2007-05-14 13:53 ` Bob Johnston
2007-05-14 14:07 ` Robert P. J. Day
2007-05-15 2:47 ` David Schwartz [this message]
2007-05-14 13:39 ` Bill Davidsen
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=MDEHLPKNGKAHNMBLJOLKCENKDMAC.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox