[patch 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.mm/init/Kconfig === --- linux-2.6-lttng.mm.orig/init/Kconfig2007-12-08 09:54:40.0 -0500 +++ linux-2.6-lttng.mm/init/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -701,6 +701,8 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.mm/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.mm/arch/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.mm/init/Kconfig === --- linux-2.6-lttng.mm.orig/init/Kconfig2007-12-08 09:54:40.0 -0500 +++ linux-2.6-lttng.mm/init/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -701,6 +701,8 @@ config PROC_PAGE_MONITOR /proc/kpagecount, and /proc/kpageflags. Disabling these interfaces will reduce the size of the kernel by approximately 4kb. +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.mm/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.mm/arch/Kconfig 2007-12-08 09:57:15.0 -0500 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-12-04 12:42:17.0 -0500 +++ linux-2.6-lttng/init/Kconfig2007-12-04 12:42:19.0 -0500 @@ -656,6 +656,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-12-04 12:42:19.0 -0500 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-12-04 12:42:17.0 -0500 +++ linux-2.6-lttng/init/Kconfig2007-12-04 12:42:19.0 -0500 @@ -656,6 +656,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-12-04 12:42:19.0 -0500 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool bla bla config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_config option it will enable Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
On Tue, 06 Nov 2007 13:12:23 -0800 H. Peter Anvin wrote: > Ideally architecture should be a Kconfig option (it's not needed before > config runs, unlike, say HOSTCC.) > > That might take some major surgery, though. I think that's what Sam was going to try to get to. He said that we need all ARCHes to source "drivers/Kconfig", so I did cris. About 5 more ARCHes need conversions. --- ~Randy - 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 1/4] Create arch/Kconfig
Ideally architecture should be a Kconfig option (it's not needed before config runs, unlike, say HOSTCC.) That might take some major surgery, though. -hpa - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
On Tue, 06 Nov 2007 13:12:23 -0800 H. Peter Anvin wrote: Ideally architecture should be a Kconfig option (it's not needed before config runs, unlike, say HOSTCC.) That might take some major surgery, though. I think that's what Sam was going to try to get to. He said that we need all ARCHes to source drivers/Kconfig, so I did cris. About 5 more ARCHes need conversions. --- ~Randy - 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 1/4] Create arch/Kconfig
Ideally architecture should be a Kconfig option (it's not needed before config runs, unlike, say HOSTCC.) That might take some major surgery, though. -hpa - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.stable/init/Kconfig === --- linux-2.6-lttng.stable.orig/init/Kconfig2007-10-30 20:20:28.0 -0400 +++ linux-2.6-lttng.stable/init/Kconfig 2007-10-30 20:21:04.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.stable/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.stable/arch/Kconfig 2007-10-30 20:20:32.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.stable/init/Kconfig === --- linux-2.6-lttng.stable.orig/init/Kconfig2007-10-30 20:20:28.0 -0400 +++ linux-2.6-lttng.stable/init/Kconfig 2007-10-30 20:21:04.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.stable/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.stable/arch/Kconfig 2007-10-30 20:20:32.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.stable/init/Kconfig === --- linux-2.6-lttng.stable.orig/init/Kconfig2007-10-30 20:20:28.0 -0400 +++ linux-2.6-lttng.stable/init/Kconfig 2007-10-30 20:21:04.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.stable/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.stable/arch/Kconfig 2007-10-30 20:20:32.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the General setup menu. Linus: Should it come with a re-duplication of it's content into each architecture, which was the case previously ? The oprofile and kprobes menu entries were litteraly cut and pasted from one architecture to another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive depends on list-of-archiectures-here might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED] CC: Linus Torvalds [EMAIL PROTECTED] CC: Sam Ravnborg [EMAIL PROTECTED] --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng.stable/init/Kconfig === --- linux-2.6-lttng.stable.orig/init/Kconfig2007-10-30 20:20:28.0 -0400 +++ linux-2.6-lttng.stable/init/Kconfig 2007-10-30 20:21:04.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source arch/Kconfig + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng.stable/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng.stable/arch/Kconfig 2007-10-30 20:20:32.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - 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/
