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 <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
