Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
>> 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' -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Add new categories of DEPRECATED and OBSOLETE.
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' -- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add new categories of DEPRECATED and OBSOLETE.
Next to EXPERIMENTAL, add two new kernel config categories of DEPRECATED and OBSOLETE. Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]> --- 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 , and 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add new categories of DEPRECATED and OBSOLETE.
Next to EXPERIMENTAL, add two new kernel config categories of DEPRECATED and OBSOLETE. Signed-off-by: Robert P. J. Day [EMAIL PROTECTED] --- 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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
