LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH]  Add new categories of DEPRECATED and OBSOLETE.
@ 2007-01-17 22:48 Robert P. J. Day
  2007-01-18  9:09 ` Cedric Le Goater
  0 siblings, 1 reply; 4+ messages in thread
From: Robert P. J. Day @ 2007-01-17 22:48 UTC (permalink / raw)
  To: Linux kernel mailing list; +Cc: Andrew Morton


  Next to EXPERIMENTAL, add two new kernel config categories of
DEPRECATED and OBSOLETE.

Signed-off-by: Robert P. J. Day <rpjday@mindspring.com>

---

  speak now or forever ... too late.


diff --git a/init/Kconfig b/init/Kconfig
index a3f83e2..433dd30 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -29,9 +29,10 @@ config EXPERIMENTAL
 	  <file:Documentation/BUG-HUNTING>, and
 	  <file:Documentation/oops-tracing.txt> in the kernel source).

-	  This option will also make obsoleted drivers available. These are
-	  drivers that have been replaced by something else, and/or are
-	  scheduled to be removed in a future kernel release.
+	  At the moment, this option also makes obsolete drivers available,
+	  but such drivers really should be removed from the EXPERIMENTAL
+	  category and added to either DEPRECATED or OBSOLETE, depending
+	  on their status.

 	  Unless you intend to help test and develop a feature or driver that
 	  falls into this category, or you have a situation that requires
@@ -40,6 +41,26 @@ config EXPERIMENTAL
 	  you say Y here, you will be offered the choice of using features or
 	  drivers that are currently considered to be in the alpha-test phase.

+config DEPRECATED
+	bool "Prompt for deprecated code/drivers"
+	default y
+	---help---
+	  Code that is tagged as "deprecated" is officially still available
+	  for use but will typically have already been scheduled for removal
+	  at some point, so it's in your best interests to start looking for
+	  an alternative.
+
+config OBSOLETE
+	bool "Prompt for obsolete code/drivers"
+	default n
+	---help---
+	  Code that is tagged as "obsolete" is officially no longer supported
+	  and shouldn't play a part in any normal build, but those features
+	  might still be available if you absolutely need access to them.
+
+	  You are *strongly* discouraged from continuing to depend on
+	  obsolete code on an ongoing, long-term basis.
+
 config BROKEN
 	bool


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH]  Add new categories of DEPRECATED and OBSOLETE.
  2007-01-17 22:48 [PATCH] Add new categories of DEPRECATED and OBSOLETE Robert P. J. Day
@ 2007-01-18  9:09 ` Cedric Le Goater
  2007-01-18  9:44   ` Robert P. J. Day
  2007-01-18 10:25   ` Jan Engelhardt
  0 siblings, 2 replies; 4+ messages in thread
From: Cedric Le Goater @ 2007-01-18  9:09 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux kernel mailing list, Andrew Morton

Robert P. J. Day wrote:
>   Next to EXPERIMENTAL, add two new kernel config categories of
> DEPRECATED and OBSOLETE.

What about adding some printks when DEPRECATED and OBSOLETE are 
set ? like in print_tainted() for example. 

C.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH]  Add new categories of DEPRECATED and OBSOLETE.
  2007-01-18  9:09 ` Cedric Le Goater
@ 2007-01-18  9:44   ` Robert P. J. Day
  2007-01-18 10:25   ` Jan Engelhardt
  1 sibling, 0 replies; 4+ messages in thread
From: Robert P. J. Day @ 2007-01-18  9:44 UTC (permalink / raw)
  To: Cedric Le Goater; +Cc: Linux kernel mailing list, Andrew Morton

On Thu, 18 Jan 2007, Cedric Le Goater wrote:

> Robert P. J. Day wrote:
> >   Next to EXPERIMENTAL, add two new kernel config categories of
> > DEPRECATED and OBSOLETE.
>
> What about adding some printks when DEPRECATED and OBSOLETE are set
> ? like in print_tainted() for example.

i preferred to introduce this as a non-intrusive change, which didn't
*require* any change to actual source code or header files.  note that
you can add these two new categories (and any other categories you
can dream up) without changing *anything* else about the build
process.  and once those two categories are in the init/Kconfig file,
subsystem maintainers can, on their own time, make the appropriate
changes to their subsystems.  it's all perfectly voluntary.

also, code that's deprecated can still be tagged with
"__attribute__((deprecated))" in the source code.

rday

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH]  Add new categories of DEPRECATED and OBSOLETE.
  2007-01-18  9:09 ` Cedric Le Goater
  2007-01-18  9:44   ` Robert P. J. Day
@ 2007-01-18 10:25   ` Jan Engelhardt
  1 sibling, 0 replies; 4+ messages in thread
From: Jan Engelhardt @ 2007-01-18 10:25 UTC (permalink / raw)
  To: Cedric Le Goater
  Cc: Robert P. J. Day, Linux kernel mailing list, Andrew Morton


>>   Next to EXPERIMENTAL, add two new kernel config categories of
>> DEPRECATED and OBSOLETE.
>
>What about adding some printks when DEPRECATED and OBSOLETE are 
>set ? like in print_tainted() for example. 

Uhm no. I don't want a load of messages just because one of these 
options is active. I'd much rather prefer that when loading a _specific 
module_ depends on DEPRECATED/OBSOLETE, a message is printed. But that's 
an extra which I doubt it is worth modifying the kernel module structure 
for.



	-`J'
-- 

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-01-18 10:26 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-17 22:48 [PATCH] Add new categories of DEPRECATED and OBSOLETE Robert P. J. Day
2007-01-18  9:09 ` Cedric Le Goater
2007-01-18  9:44   ` Robert P. J. Day
2007-01-18 10:25   ` Jan Engelhardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).