+ create-arch-kconfig.patch added to -mm tree

+ create-arch-kconfig.patch added to -mm tree

[akpm]

The patch titled
     Create arch/Kconfig
has been added to the -mm tree.  Its filename is
     create-arch-kconfig.patch

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

------------------------------------------------------
Subject: Create arch/Kconfig
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>

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 <mathieu.desnoyers@polymtl.ca>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/Kconfig |    3 +++
 init/Kconfig |    2 ++
 2 files changed, 5 insertions(+)

diff -puN /dev/null arch/Kconfig
--- /dev/null
+++ a/arch/Kconfig
@@ -0,0 +1,3 @@
+#
+# General architecture dependent options
+#
diff -puN init/Kconfig~create-arch-kconfig init/Kconfig
--- a/init/Kconfig~create-arch-kconfig
+++ a/init/Kconfig
@@ -673,6 +673,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
_

Patches currently in -mm which might be from mathieu.desnoyers@polymtl.ca are

origin.patch
add-cmpxchg_local-to-asm-generic-for-per-cpu-atomic-operations.patch
fall-back-on-interrupt-disable-in-cmpxchg8b-on-80386-and-80486.patch
add-cmpxchg64-and-cmpxchg64_local-to-alpha.patch
add-cmpxchg64-and-cmpxchg64_local-to-mips.patch
add-cmpxchg64-and-cmpxchg64_local-to-powerpc.patch
add-cmpxchg64-and-cmpxchg64_local-to-x86_64.patch
add-cmpxchg_local-to-arm.patch
add-cmpxchg_local-to-avr32.patch
add-cmpxchg_local-to-blackfin-replace-__cmpxchg-by-generic-cmpxchg.patch
add-cmpxchg_local-to-cris.patch
add-cmpxchg_local-to-frv.patch
add-cmpxchg_local-to-h8300.patch
add-cmpxchg_local-cmpxchg64-and-cmpxchg64_local-to-ia64.patch
new-cmpxchg_local-optimized-for-up-case-for-m32r.patch
fix-m32r-__xchg.patch
m32r-build-fix-of-arch-m32r-kernel-smpbootc.patch
local_t-m32r-use-architecture-specific-cmpxchg_local.patch
add-cmpxchg_local-to-m86k.patch
add-cmpxchg_local-to-m68knommu.patch
add-cmpxchg_local-to-parisc.patch
add-cmpxchg_local-to-ppc.patch
add-cmpxchg_local-to-s390.patch
add-cmpxchg_local-to-sh-use-generic-cmpxchg-instead-of-cmpxchg_u32.patch
add-cmpxchg_local-to-sh64.patch
add-cmpxchg_local-to-sparc-move-__cmpxchg-to-systemh.patch
add-cmpxchg_local-to-sparc64.patch
add-cmpxchg_local-to-v850.patch
add-cmpxchg_local-to-xtensa.patch
create-arch-kconfig.patch
add-arch_supports_oprofile.patch
add-arch_supports_kprobes.patch
move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch

Re: + create-arch-kconfig.patch added to -mm tree

[Mathieu Desnoyers]

* akpm@linux-foundation.org (akpm@linux-foundation.org) wrote:
> 
> The patch titled
>      Create arch/Kconfig
> has been added to the -mm tree.  Its filename is
>      create-arch-kconfig.patch
> 

Hi Andrew,

I have an updated patchset for these 4 instrumentation menu patches,
following Sam Ravnborg's comments (using ARCH_HAS_* instead of
ARCH_SUPPORTS_*). I was planning to send them with my next patch round.

create-arch-kconfig.patch
add-arch_supports_oprofile.patch
add-arch_supports_kprobes.patch
move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch

Mathieu

> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> 
> See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
> out what to do about this
> 
> ------------------------------------------------------
> Subject: Create arch/Kconfig
> From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> 
> 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 <mathieu.desnoyers@polymtl.ca>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: <linux-arch@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/Kconfig |    3 +++
>  init/Kconfig |    2 ++
>  2 files changed, 5 insertions(+)
> 
> diff -puN /dev/null arch/Kconfig
> --- /dev/null
> +++ a/arch/Kconfig
> @@ -0,0 +1,3 @@
> +#
> +# General architecture dependent options
> +#
> diff -puN init/Kconfig~create-arch-kconfig init/Kconfig
> --- a/init/Kconfig~create-arch-kconfig
> +++ a/init/Kconfig
> @@ -673,6 +673,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
> _
> 
> Patches currently in -mm which might be from mathieu.desnoyers@polymtl.ca are
> 
> origin.patch
> add-cmpxchg_local-to-asm-generic-for-per-cpu-atomic-operations.patch
> fall-back-on-interrupt-disable-in-cmpxchg8b-on-80386-and-80486.patch
> add-cmpxchg64-and-cmpxchg64_local-to-alpha.patch
> add-cmpxchg64-and-cmpxchg64_local-to-mips.patch
> add-cmpxchg64-and-cmpxchg64_local-to-powerpc.patch
> add-cmpxchg64-and-cmpxchg64_local-to-x86_64.patch
> add-cmpxchg_local-to-arm.patch
> add-cmpxchg_local-to-avr32.patch
> add-cmpxchg_local-to-blackfin-replace-__cmpxchg-by-generic-cmpxchg.patch
> add-cmpxchg_local-to-cris.patch
> add-cmpxchg_local-to-frv.patch
> add-cmpxchg_local-to-h8300.patch
> add-cmpxchg_local-cmpxchg64-and-cmpxchg64_local-to-ia64.patch
> new-cmpxchg_local-optimized-for-up-case-for-m32r.patch
> fix-m32r-__xchg.patch
> m32r-build-fix-of-arch-m32r-kernel-smpbootc.patch
> local_t-m32r-use-architecture-specific-cmpxchg_local.patch
> add-cmpxchg_local-to-m86k.patch
> add-cmpxchg_local-to-m68knommu.patch
> add-cmpxchg_local-to-parisc.patch
> add-cmpxchg_local-to-ppc.patch
> add-cmpxchg_local-to-s390.patch
> add-cmpxchg_local-to-sh-use-generic-cmpxchg-instead-of-cmpxchg_u32.patch
> add-cmpxchg_local-to-sh64.patch
> add-cmpxchg_local-to-sparc-move-__cmpxchg-to-systemh.patch
> add-cmpxchg_local-to-sparc64.patch
> add-cmpxchg_local-to-v850.patch
> add-cmpxchg_local-to-xtensa.patch
> create-arch-kconfig.patch
> add-arch_supports_oprofile.patch
> add-arch_supports_kprobes.patch
> move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: + create-arch-kconfig.patch added to -mm tree

[Andrew Morton]

On Thu, 15 Nov 2007 20:57:30 -0500 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:

> I have an updated patchset for these 4 instrumentation menu patches,
> following Sam Ravnborg's comments (using ARCH_HAS_* instead of
> ARCH_SUPPORTS_*). I was planning to send them with my next patch round.
> 
> create-arch-kconfig.patch
> add-arch_supports_oprofile.patch
> add-arch_supports_kprobes.patch
> move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch

So I've fixed all the rejects, fixed it all up for the arch/x86/Kconfig
churn, merged another patchset which depends on this one and now I'm told
that they need to be updated?

Sigh.  Normally I know not to look at a Mathieu patch until it hits version 37,
but I wanted to merge
kprobes-indicate-kretprobe-support-in-arch-arch-kconfig.patch and
kprobes-build-kretprobe-samples-only-if-arch-supports-kretprobes.patch
which depend on these patches.

It seems that they will now break.  afacit I'll need to do
s/CONFIG_ARCH_SUPPORTS_KRETPROBES/CONFIG_ARCH_HAD_KRETPROBES/ on those
patches.

Please send updated versions of these four asap?

Re: + create-arch-kconfig.patch added to -mm tree

[Mathieu Desnoyers]

* Andrew Morton (akpm@linux-foundation.org) wrote:
> On Thu, 15 Nov 2007 20:57:30 -0500 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> 
> > I have an updated patchset for these 4 instrumentation menu patches,
> > following Sam Ravnborg's comments (using ARCH_HAS_* instead of
> > ARCH_SUPPORTS_*). I was planning to send them with my next patch round.
> > 
> > create-arch-kconfig.patch
> > add-arch_supports_oprofile.patch
> > add-arch_supports_kprobes.patch
> > move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
> 
> So I've fixed all the rejects, fixed it all up for the arch/x86/Kconfig
> churn, merged another patchset which depends on this one and now I'm told
> that they need to be updated?
> 
> Sigh.  Normally I know not to look at a Mathieu patch until it hits version 37,
> but I wanted to merge
> kprobes-indicate-kretprobe-support-in-arch-arch-kconfig.patch and
> kprobes-build-kretprobe-samples-only-if-arch-supports-kretprobes.patch
> which depend on these patches.
> 
> It seems that they will now break.  afacit I'll need to do
> s/CONFIG_ARCH_SUPPORTS_KRETPROBES/CONFIG_ARCH_HAD_KRETPROBES/ on those
> patches.
> 
> Please send updated versions of these four asap?


Just been sent.

I sent you an email telling to hold patch integration yesterday:

Subject: Wait for next round of post before merge to -mm

I thought it was clear, but apparently it wasn't, sorry about that.

And the change involves using a select now instead of a simple depend.

Mathieu


-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: + create-arch-kconfig.patch added to -mm tree

[Russell King]

On Thu, Nov 15, 2007 at 06:07:22PM -0800, Andrew Morton wrote:
> On Thu, 15 Nov 2007 20:57:30 -0500 Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > I have an updated patchset for these 4 instrumentation menu patches,
> > following Sam Ravnborg's comments (using ARCH_HAS_* instead of
> > ARCH_SUPPORTS_*). I was planning to send them with my next patch round.
> > 
> > create-arch-kconfig.patch
> > add-arch_supports_oprofile.patch
> > add-arch_supports_kprobes.patch
> > move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch
> 
> So I've fixed all the rejects, fixed it all up for the arch/x86/Kconfig
> churn, merged another patchset which depends on this one and now I'm told
> that they need to be updated?

Well, the discussion on linux-arch about what to use started some 11
hours before your original merge mail.  Maybe you missed it?

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: + create-arch-kconfig.patch added to -mm tree

[Russell King]

On Thu, Nov 15, 2007 at 02:27:05PM -0800, akpm@linux-foundation.org wrote:
> 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

I thought we were discussing the prefix to use, and settling on HAVE_xxx
rather than ARCH_SUPPORTS_xxx.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: + create-arch-kconfig.patch added to -mm tree

[Mathieu Desnoyers]

* Russell King (rmk@arm.linux.org.uk) wrote:
> On Thu, Nov 15, 2007 at 02:27:05PM -0800, akpm@linux-foundation.org wrote:
> > 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
> 
> I thought we were discussing the prefix to use, and settling on HAVE_xxx
> rather than ARCH_SUPPORTS_xxx.
> 

The latest version I sent uses HAVE_xxx

see :

http://www.gossamer-threads.com/lists/linux/kernel/844040?do=post_view_threaded
(and other messages in that thread)

Mathieu


> -- 
> Russell King
>  Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
>  maintainer of:

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

+ create-arch-kconfig.patch added to -mm tree

[akpm]

The patch titled
     Create arch/Kconfig
has been added to the -mm tree.  Its filename is
     create-arch-kconfig.patch

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

------------------------------------------------------
Subject: Create arch/Kconfig
From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>

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_HAS        51
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 <mathieu.desnoyers@polymtl.ca>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: <linux-arch@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 arch/Kconfig |    3 +++
 init/Kconfig |    2 ++
 2 files changed, 5 insertions(+)

diff -puN /dev/null arch/Kconfig
--- /dev/null
+++ a/arch/Kconfig
@@ -0,0 +1,3 @@
+#
+# General architecture dependent options
+#
diff -puN init/Kconfig~create-arch-kconfig init/Kconfig
--- a/init/Kconfig~create-arch-kconfig
+++ a/init/Kconfig
@@ -695,6 +695,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
_

Patches currently in -mm which might be from mathieu.desnoyers@polymtl.ca are

origin.patch
add-cmpxchg_local-to-asm-generic-for-per-cpu-atomic-operations.patch
fall-back-on-interrupt-disable-in-cmpxchg8b-on-80386-and-80486.patch
add-cmpxchg64-and-cmpxchg64_local-to-alpha.patch
add-cmpxchg64-and-cmpxchg64_local-to-mips.patch
add-cmpxchg64-and-cmpxchg64_local-to-powerpc.patch
add-cmpxchg64-and-cmpxchg64_local-to-x86_64.patch
add-cmpxchg_local-to-arm.patch
add-cmpxchg_local-to-avr32.patch
add-cmpxchg_local-to-blackfin-replace-__cmpxchg-by-generic-cmpxchg.patch
add-cmpxchg_local-to-cris.patch
add-cmpxchg_local-to-frv.patch
add-cmpxchg_local-to-h8300.patch
add-cmpxchg_local-cmpxchg64-and-cmpxchg64_local-to-ia64.patch
new-cmpxchg_local-optimized-for-up-case-for-m32r.patch
fix-m32r-__xchg.patch
m32r-build-fix-of-arch-m32r-kernel-smpbootc.patch
local_t-m32r-use-architecture-specific-cmpxchg_local.patch
add-cmpxchg_local-to-m86k.patch
add-cmpxchg_local-to-m68knommu.patch
add-cmpxchg_local-to-parisc.patch
add-cmpxchg_local-to-ppc.patch
add-cmpxchg_local-to-s390.patch
add-cmpxchg_local-to-sh-use-generic-cmpxchg-instead-of-cmpxchg_u32.patch
add-cmpxchg_local-to-sh64.patch
add-cmpxchg_local-to-sparc-move-__cmpxchg-to-systemh.patch
add-cmpxchg_local-to-sparc64.patch
add-cmpxchg_local-to-v850.patch
add-cmpxchg_local-to-xtensa.patch
create-arch-kconfig.patch
add-arch_supports_oprofile.patch
add-arch_supports_kprobes.patch
move-kconfiginstrumentation-to-arch-kconfig-and-init-kconfig.patch