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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 17 Jan 2007 17:04:20 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Valdis.Kletnieks@...edu
cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: "obsolete" versus "deprecated", and a new config option?

On Wed, 17 Jan 2007, Valdis.Kletnieks@...edu wrote:

> On Wed, 17 Jan 2007 11:51:27 EST, "Robert P. J. Day" said:
> >
> >   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.
>
> How much of the 'OBSOLETE' code should just be labelled 'BROKEN'
> instead?

the stuff that's actually "broken."  :-)

OBSOLETE is not (or at least *should not* be) equivalent to BROKEN.
"OBSOLETE" should denote code that, while it is no longer supported
and has a viable replacement, may very well still work.  and it may or
may not be slated for removal some day.  there may very well be
reasons to keep "obsolete" code in the kernel, for occasional backward
compatibility, but marking it as "obsolete" is a powerful indicator
that people should *really* try not to use it.

"BROKEN" code, OTOH, really should mean exactly that -- code that is
*known* to be broken.  that would include old code that has suffered
bit rot, but it might also include *new* code that, while it's now
part of the kernel, someone discovers a major flaw in it and no one's
got around to fixing it yet.  so even bleeding-edge code can
technically be "broken" until someone gets around to debugging it.

thoughts?

rday

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