Re: "obsolete" versus "deprecated", and a new config option?

["Robert P. J. Day" <rpjday@mindspring.com>]

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

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

config MTD_AMDSTD
        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.

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