linux-kernel - Re: [PATCH] Introduce two new maturlty levels: DEPRECATED and OBSOLETE.

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Jan 2007 05:38:14 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Introduce two new maturlty levels:  DEPRECATED and
 OBSOLETE.

On Thu, 18 Jan 2007, Jan Engelhardt wrote:

>
> >On Wed, 17 Jan 2007, H. Peter Anvin wrote:
> >
> >> DEPRECATED should presumably default to Y; OBSOLETE to n.
> >
> >crap, now i see what you were getting at -- i forgot to assign
> >defaults.  i'll resubmit, but i'll wait for anyone to suggest any
> >better help content if they have a better idea.
>
> Well... _maybe_ documentation/scheduled-removal.txt (or whatever it
> is called) could now be merged into the kconfig options and help
> text. Or maybe not, to keep it easy to track deprecated code.
>
> Well, even if scheduled-removal.txt stays, you could submit a 2nd
> patch putting OBSOLETE and DEPRECATED tags to the Kconfig options
> listed in scheduled-removal.txt, so that kconfig+sched are in sync.

i'm assuming you mean "Documentation/feature-removal-schedule.txt".
that would *seem* to make sense, after only a few seconds of thought.
once config options are tagged with either DEPRECATED or OBSOLETE,
surely it wouldn't be hard to be able to pull out a list of those from
the source tree, based on their Kconfig dependencies.

but, again, that's getting ahead of ourselves.  certainly, it's
something that *could* be done at some point, but not knowing exactly
how one would do that doesn't stop anyone from adding those two config
settings *now*, just to get the process rolling.

let's not over-analyze this too much.

rday

p.s.  it might be worth perusing the feature removal file, to see what
features are still listed there even though they were scheduled to be
removed some time ago.  just a thought.
-
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/