[PATCH] Revert "Permit silencing of __deprecated warnings."

[PATCH] Revert "Permit silencing of __deprecated warnings."

[Jason Gunthorpe]

This reverts commit de48844398f81cfdf087d56e12c920d620dae8d5.

Linus would prefer that __deprecated never produce a warning in an
allyesconfig compile. Since we have been at this state for some time,
the option no longer has a purpose.

Link: https://lkml.kernel.org/r/CA+55aFyGLKSzS8O3m4JaE69wUm03tGOf+507jCCViTRQaGBGxw@mail.gmail.com
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
---
 Documentation/process/4.Coding.rst | 2 +-
 include/linux/compiler_types.h     | 6 ------
 lib/Kconfig.debug                  | 8 --------
 3 files changed, 1 insertion(+), 15 deletions(-)

Linus: As discussed.

Jonathan: I'm not sure if you prefer diffs to documentation to be
minimal like this, or if should reflow the paragraph?

I can send this in a PR via rdma.git with the __deprecation removal
patch probably Monday/Tuesday if there is agreement, no 0-day
surprises, etc.

Cheers,
Jason

diff --git a/Documentation/process/4.Coding.rst b/Documentation/process/4.Coding.rst
index eb4b185d168c05..f03c62f50d7d0a 100644
--- a/Documentation/process/4.Coding.rst
+++ b/Documentation/process/4.Coding.rst
@@ -249,7 +249,7 @@ features; most of these are found in the "kernel hacking" submenu.  Several
 of these options should be turned on for any kernel used for development or
 testing purposes.  In particular, you should turn on:
 
- - ENABLE_WARN_DEPRECATED, ENABLE_MUST_CHECK, and FRAME_WARN to get an
+ - ENABLE_MUST_CHECK, and FRAME_WARN to get an
    extra set of warnings for problems like the use of deprecated interfaces
    or ignoring an important return value from a function.  The output
    generated by these warnings can be verbose, but one need not worry about
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index a8ba6b04152c13..a2b428c43ae134 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -135,12 +135,6 @@ struct ftrace_likely_data {
 #undef __must_check
 #define __must_check
 #endif
-#ifndef CONFIG_ENABLE_WARN_DEPRECATED
-#undef __deprecated
-#undef __deprecated_for_modules
-#define __deprecated
-#define __deprecated_for_modules
-#endif
 
 #ifndef __malloc
 #define __malloc
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6e73904c5a5da..ab1b599202bca7 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -211,14 +211,6 @@ config GDB_SCRIPTS
 	  instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
 	  for further details.
 
-config ENABLE_WARN_DEPRECATED
-	bool "Enable __deprecated logic"
-	default y
-	help
-	  Enable the __deprecated logic in the kernel build.
-	  Disable this to suppress the "warning: 'foo' is deprecated
-	  (declared at kernel/power/somefile.c:1234)" messages.
-
 config ENABLE_MUST_CHECK
 	bool "Enable __must_check logic"
 	default y
-- 
2.18.0

Re: [PATCH] Revert "Permit silencing of __deprecated warnings."

[Linus Torvalds]

On Fri, Aug 17, 2018 at 7:45 PM Jason Gunthorpe <jgg@mellanox.com> wrote:
>
> Linus would prefer that __deprecated never produce a warning in an
> allyesconfig compile. Since we have been at this state for some time,
> the option no longer has a purpose.

I got rid of the option, but of the code too, and - trying to set a
good example - looked around for actual users and got rid of one
long-deprecated function that hasn't had an in-kernel user in four
years.

If there are some out-of-kernel modules still using
pcmcia_request_exclusive_irq(), I can only say "Oh wow, you haven't
fixed your broken out-of-tree module in the 8 years it has been
deprecated, see how much I care about your complaints now".

Maybe somebody will be willing to look at other cases of __deprecated,
but at least I won't be seeing warnings about it any more.

               Linus

Re: [PATCH] Revert "Permit silencing of __deprecated warnings."

[Jonathan Corbet]

On Fri, 17 Aug 2018 20:45:06 -0600
Jason Gunthorpe <jgg@mellanox.com> wrote:

> Jonathan: I'm not sure if you prefer diffs to documentation to be
> minimal like this, or if should reflow the paragraph?

I guess I've never really thought to develop a strong preference.  But,
in the end, the docs are meant to be read in their source form, so we
want to keep them readable.  If a paragraph needs to be refilled due to
significant changes, just go ahead and do it...

jon