HugeTLB vs. SH3 cpu

HugeTLB vs. SH3 cpu

[Adrian Bunk]

fs/Kconfig says:

config HUGETLBFS
        bool "HugeTLB file system support"
        depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN


arch/sh/mm/Kconfig says:

choice
        prompt "HugeTLB page size"
        depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU


The compiler says with CONFIG_CPU_SH3:

<--  snip  -->

...
  CC      arch/sh/mm/hugetlbpage.o
In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/arch/sh/mm/hugetlbpage.c:14:/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hugetlb.h: In function 'prepare_hugepage_range':
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hugetlb.h:73: error: 'HPAGE_SHIFT' undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hugetlb.h:73: error: (Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/hugetlb.h:73: error: for each function it appears in.)
make[2]: *** [arch/sh/mm/hugetlbpage.o] Error 1

<--  snip  -->


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: HugeTLB vs. SH3 cpu

[Nish Aravamudan]

On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> fs/Kconfig says:
>
>  config HUGETLBFS
>         bool "HugeTLB file system support"
>         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
>
>
>  arch/sh/mm/Kconfig says:
>
>  choice
>         prompt "HugeTLB page size"
>         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU

So the problem is that SH3 is allowed to enable
HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
due to some #ifdeffery on the hugepage size. So either the choice
needs to be extended to include CPU_SH3 (which builds here, when
changed) or the HUGETLBFS conditional needs to depend more
specifically on SH4/5 and not just SUPERH. I think the arch maintainer
has to make that call, as I don't know the hardware to say if SH3
actually supports multiple hugepage sizes.

Thanks,
Nish

Re: HugeTLB vs. SH3 cpu

[Paul Mundt]

On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> > fs/Kconfig says:
> >
> >  config HUGETLBFS
> >         bool "HugeTLB file system support"
> >         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> >
> >
> >  arch/sh/mm/Kconfig says:
> >
> >  choice
> >         prompt "HugeTLB page size"
> >         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU
> 
> So the problem is that SH3 is allowed to enable
> HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
> due to some #ifdeffery on the hugepage size. So either the choice
> needs to be extended to include CPU_SH3 (which builds here, when
> changed) or the HUGETLBFS conditional needs to depend more
> specifically on SH4/5 and not just SUPERH. I think the arch maintainer
> has to make that call, as I don't know the hardware to say if SH3
> actually supports multiple hugepage sizes.
> 
The problem is that the hugetlb Kconfig stuff is a complete mess. There's
a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
depend on each other.

Sorting out the mess noted by Adrian is pretty trivial with a
HAVE_HUGETLB_PAGE. How about this?

Signed-off-by: Paul Mundt <lethal@linux-sh.org>

---

 arch/ia64/Kconfig                      |    1 +
 arch/powerpc/platforms/Kconfig.cputype |    1 +
 arch/sh/Kconfig                        |    2 ++
 arch/sparc64/Kconfig                   |    1 +
 arch/x86/Kconfig                       |    1 +
 fs/Kconfig                             |    3 ++-
 mm/Kconfig                             |    3 +++
 7 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 8fa3faf..bb1e02b 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -19,6 +19,7 @@ config IA64
 	select HAVE_OPROFILE
 	select HAVE_KPROBES
 	select HAVE_KRETPROBES
+	select HAVE_HUGETLB_PAGE
 	default y
 	help
 	  The Itanium Processor Family is Intel's 64-bit successor to
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 0c3face..7c937ad 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -1,5 +1,6 @@
 config PPC64
 	bool "64-bit kernel"
+	select HAVE_HUGETLB_PAGE
 	default n
 	help
 	  This option selects whether a 32-bit or a 64-bit kernel
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index df2e2f9..c48f629 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -114,6 +114,7 @@ config CPU_SH3
 
 config CPU_SH4
 	bool
+	select HAVE_HUGETLB_PAGE
 	select CPU_HAS_INTEVT
 	select CPU_HAS_SR_RB
 	select CPU_HAS_PTEA if !CPU_SH4A || CPU_SHX2
@@ -130,6 +131,7 @@ config CPU_SH4AL_DSP
 
 config CPU_SH5
 	bool
+	select HAVE_HUGETLB_PAGE
 	select CPU_HAS_FPU
 
 config CPU_SHX2
diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
index 463d1be..3045673 100644
--- a/arch/sparc64/Kconfig
+++ b/arch/sparc64/Kconfig
@@ -16,6 +16,7 @@ config SPARC64
 	bool
 	default y
 	select HAVE_IDE
+	select HAVE_HUGETLB_PAGE
 	help
 	  SPARC is a family of RISC microprocessors designed and marketed by
 	  Sun Microsystems, incorporated.  This port covers the newer 64-bit
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 6c70fed..d91e7b7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -22,6 +22,7 @@ config X86
 	select HAVE_OPROFILE
 	select HAVE_KPROBES
 	select HAVE_KRETPROBES
+	select HAVE_HUGETLB_PAGE
 	select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
 
 
diff --git a/fs/Kconfig b/fs/Kconfig
index d731282..f886ae2 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
 
 config HUGETLBFS
 	bool "HugeTLB file system support"
-	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
+	depends on HAVE_HUGETLB_PAGE || BROKEN
 	help
 	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
 	  ramfs. For architectures that support it, say Y here and read
@@ -987,6 +987,7 @@ config HUGETLBFS
 	  If unsure, say N.
 
 config HUGETLB_PAGE
+	depends on MMU
 	def_bool HUGETLBFS
 
 config CONFIGFS_FS
diff --git a/mm/Kconfig b/mm/Kconfig
index 0016ebd..3113374 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -90,6 +90,9 @@ config HAVE_MEMORY_PRESENT
 	def_bool y
 	depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
 
+config HAVE_HUGETLB_PAGE
+	def_bool n
+
 #
 # SPARSEMEM_EXTREME (which is the default) does some bootmem
 # allocations when memory_present() is called.  If this cannot

Re: HugeTLB vs. SH3 cpu

[Mel Gorman]

On (02/04/08 17:04), Paul Mundt didst pronounce:
> On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> > > fs/Kconfig says:
> > >
> > >  config HUGETLBFS
> > >         bool "HugeTLB file system support"
> > >         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > >
> > >
> > >  arch/sh/mm/Kconfig says:
> > >
> > >  choice
> > >         prompt "HugeTLB page size"
> > >         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU
> > 
> > So the problem is that SH3 is allowed to enable
> > HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
> > due to some #ifdeffery on the hugepage size. So either the choice
> > needs to be extended to include CPU_SH3 (which builds here, when
> > changed) or the HUGETLBFS conditional needs to depend more
> > specifically on SH4/5 and not just SUPERH. I think the arch maintainer
> > has to make that call, as I don't know the hardware to say if SH3
> > actually supports multiple hugepage sizes.
> > 
> The problem is that the hugetlb Kconfig stuff is a complete mess. There's
> a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
> depend on each other.
> 

I believe the original intention was that HUGETLB_PAGE would build the
hugepage pool and the arch-specific code and HUGETLBFS would be the userspace
interface but not necessarily the only one. Whatever the original intention,
it's no longer the case as they have become inter-dependant. Fixing it is
not straight-forward but I don't think we want to collapse HUGETLB_PAGE and
HUGETLBFS just yet either.

> Sorting out the mess noted by Adrian is pretty trivial with a
> HAVE_HUGETLB_PAGE. How about this?
> 

While I am loathe to add yet more hugetlb-related Kconfig options, this
does seem to be the common way of dealing with features that depend on the
architecture (e.g. HAVE_OPROFILE, HAVE_IDE, HAVE_KPROBES etc.).

> Signed-off-by: Paul Mundt <lethal@linux-sh.org>
> 

It appears to be doing the right thing making defconfig across the different
architectures.

Acked-by: Mel Gorman <mel@csn.ul.ie>

> ---
> 
>  arch/ia64/Kconfig                      |    1 +
>  arch/powerpc/platforms/Kconfig.cputype |    1 +
>  arch/sh/Kconfig                        |    2 ++
>  arch/sparc64/Kconfig                   |    1 +
>  arch/x86/Kconfig                       |    1 +
>  fs/Kconfig                             |    3 ++-
>  mm/Kconfig                             |    3 +++
>  7 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
> index 8fa3faf..bb1e02b 100644
> --- a/arch/ia64/Kconfig
> +++ b/arch/ia64/Kconfig
> @@ -19,6 +19,7 @@ config IA64
>  	select HAVE_OPROFILE
>  	select HAVE_KPROBES
>  	select HAVE_KRETPROBES
> +	select HAVE_HUGETLB_PAGE
>  	default y
>  	help
>  	  The Itanium Processor Family is Intel's 64-bit successor to
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 0c3face..7c937ad 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -1,5 +1,6 @@
>  config PPC64
>  	bool "64-bit kernel"
> +	select HAVE_HUGETLB_PAGE
>  	default n
>  	help
>  	  This option selects whether a 32-bit or a 64-bit kernel

hmm... This is what Kconfig is currently doing but by rights, it should be
set on a per-processor basis. I guess it's outside the scope of this patch as
there isn't an obvious way to tell what processor versions support huge pages.

> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index df2e2f9..c48f629 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -114,6 +114,7 @@ config CPU_SH3
>  
>  config CPU_SH4
>  	bool
> +	select HAVE_HUGETLB_PAGE
>  	select CPU_HAS_INTEVT
>  	select CPU_HAS_SR_RB
>  	select CPU_HAS_PTEA if !CPU_SH4A || CPU_SHX2
> @@ -130,6 +131,7 @@ config CPU_SH4AL_DSP
>  
>  config CPU_SH5
>  	bool
> +	select HAVE_HUGETLB_PAGE
>  	select CPU_HAS_FPU
>  
>  config CPU_SHX2
> diff --git a/arch/sparc64/Kconfig b/arch/sparc64/Kconfig
> index 463d1be..3045673 100644
> --- a/arch/sparc64/Kconfig
> +++ b/arch/sparc64/Kconfig
> @@ -16,6 +16,7 @@ config SPARC64
>  	bool
>  	default y
>  	select HAVE_IDE
> +	select HAVE_HUGETLB_PAGE
>  	help
>  	  SPARC is a family of RISC microprocessors designed and marketed by
>  	  Sun Microsystems, incorporated.  This port covers the newer 64-bit
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 6c70fed..d91e7b7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -22,6 +22,7 @@ config X86
>  	select HAVE_OPROFILE
>  	select HAVE_KPROBES
>  	select HAVE_KRETPROBES
> +	select HAVE_HUGETLB_PAGE
>  	select HAVE_KVM if ((X86_32 && !X86_VOYAGER && !X86_VISWS && !X86_NUMAQ) || X86_64)
>  
>  
> diff --git a/fs/Kconfig b/fs/Kconfig
> index d731282..f886ae2 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
>  
>  config HUGETLBFS
>  	bool "HugeTLB file system support"
> -	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> +	depends on HAVE_HUGETLB_PAGE || BROKEN
>  	help
>  	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
>  	  ramfs. For architectures that support it, say Y here and read
> @@ -987,6 +987,7 @@ config HUGETLBFS
>  	  If unsure, say N.
>  
>  config HUGETLB_PAGE
> +	depends on MMU
>  	def_bool HUGETLBFS
>  
>  config CONFIGFS_FS
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 0016ebd..3113374 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -90,6 +90,9 @@ config HAVE_MEMORY_PRESENT
>  	def_bool y
>  	depends on ARCH_HAVE_MEMORY_PRESENT || SPARSEMEM
>  
> +config HAVE_HUGETLB_PAGE
> +	def_bool n
> +
>  #
>  # SPARSEMEM_EXTREME (which is the default) does some bootmem
>  # allocations when memory_present() is called.  If this cannot

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

Re: HugeTLB vs. SH3 cpu

[Paul Mundt]

On Wed, Apr 02, 2008 at 11:15:38AM +0100, Mel Gorman wrote:
> On (02/04/08 17:04), Paul Mundt didst pronounce:
> > The problem is that the hugetlb Kconfig stuff is a complete mess. There's
> > a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
> > depend on each other.
> 
> I believe the original intention was that HUGETLB_PAGE would build the
> hugepage pool and the arch-specific code and HUGETLBFS would be the userspace
> interface but not necessarily the only one. Whatever the original intention,
> it's no longer the case as they have become inter-dependant. Fixing it is
> not straight-forward but I don't think we want to collapse HUGETLB_PAGE and
> HUGETLBFS just yet either.
> 
That makes more sense, perhaps it's worth beating in to shape so there
can also be non hugetlbfs users, this needs a bit of use-case thinking,
though.

> > diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> > index 0c3face..7c937ad 100644
> > --- a/arch/powerpc/platforms/Kconfig.cputype
> > +++ b/arch/powerpc/platforms/Kconfig.cputype
> > @@ -1,5 +1,6 @@
> >  config PPC64
> >  	bool "64-bit kernel"
> > +	select HAVE_HUGETLB_PAGE
> >  	default n
> >  	help
> >  	  This option selects whether a 32-bit or a 64-bit kernel
> 
> hmm... This is what Kconfig is currently doing but by rights, it should be
> set on a per-processor basis. I guess it's outside the scope of this patch as
> there isn't an obvious way to tell what processor versions support huge pages.
> 
Yes, I had the same thoughts, perhaps the PPC64 folks can shed some light
on this.

Re: HugeTLB vs. SH3 cpu

[Nishanth Aravamudan]

On 02.04.2008 [17:04:48 +0900], Paul Mundt wrote:
> On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > On 4/1/08, Adrian Bunk <bunk@kernel.org> wrote:
> > > fs/Kconfig says:
> > >
> > >  config HUGETLBFS
> > >         bool "HugeTLB file system support"
> > >         depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > >
> > >
> > >  arch/sh/mm/Kconfig says:
> > >
> > >  choice
> > >         prompt "HugeTLB page size"
> > >         depends on HUGETLB_PAGE && (CPU_SH4 || CPU_SH5) && MMU
> > 
> > So the problem is that SH3 is allowed to enable
> > HUGETLB_PAGE/HUGETLBFS, but only SH4/5 define the HPAGE_SHIFT macro,
> > due to some #ifdeffery on the hugepage size. So either the choice
> > needs to be extended to include CPU_SH3 (which builds here, when
> > changed) or the HUGETLBFS conditional needs to depend more
> > specifically on SH4/5 and not just SUPERH. I think the arch maintainer
> > has to make that call, as I don't know the hardware to say if SH3
> > actually supports multiple hugepage sizes.
> > 
> The problem is that the hugetlb Kconfig stuff is a complete mess. There's
> a semi-decoupling between HUGETLBFS and HUGETLB_PAGE, though they both
> depend on each other.
> 
> Sorting out the mess noted by Adrian is pretty trivial with a
> HAVE_HUGETLB_PAGE. How about this?

I'm confused, isn't the following simpler fix equivalent?

Fix sh3 build with HUGETLBFS=y. Only SH4 and SH5 actually support
HUGETLB_PAGE (which HUGETLBFS depends on).

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>

diff --git a/fs/Kconfig b/fs/Kconfig
index d731282..1981f8e 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
 
 config HUGETLBFS
 	bool "HugeTLB file system support"
-	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
+	depends on X86 || IA64 || PPC64 || SPARC64 || ((CPU_SH4 || CPU_SH5) && MMU) || BROKEN
 	help
 	  hugetlbfs is a filesystem backing for HugeTLB pages, based on
 	  ramfs. For architectures that support it, say Y here and read

Re: HugeTLB vs. SH3 cpu

[Dave Hansen]

On Wed, 2008-04-02 at 15:55 -0700, Nishanth Aravamudan wrote:
> On 02.04.2008 [17:04:48 +0900], Paul Mundt wrote:
> > On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > Sorting out the mess noted by Adrian is pretty trivial with a
> > HAVE_HUGETLB_PAGE. How about this?
> 
> I'm confused, isn't the following simpler fix equivalent?
> 
> Fix sh3 build with HUGETLBFS=y. Only SH4 and SH5 actually support
> HUGETLB_PAGE (which HUGETLBFS depends on).
> 
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> 
> diff --git a/fs/Kconfig b/fs/Kconfig
> index d731282..1981f8e 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
>  
>  config HUGETLBFS
>  	bool "HugeTLB file system support"
> -	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> +	depends on X86 || IA64 || PPC64 || SPARC64 || ((CPU_SH4 || CPU_SH5) && MMU) || BROKEN

Yeah, that's equivalent.  But, you have to draw the line at some point
on how complex that "depends on" is going to get.  I think you each have
unique pain tolerances. :)

Personally, I kinda prefer to break it out per-arch, because that SUPERH
logic is getting a bit screwy.

You could also do something like this:

>  config HUGETLBFS
>  	bool "HugeTLB file system support"
> -	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> +	depends on X86 || IA64 || PPC64 || SPARC64 || SUPERH_HUGETLBFS || BROKEN

And then:

config SUPERH_HUGETLBFS
	def_bool y
	depends on (CPU_SH4 || CPU_SH5) && MMU

on the arch-specific side.  

-- Dave

Re: HugeTLB vs. SH3 cpu

[Paul Mundt]

On Wed, Apr 02, 2008 at 05:06:09PM -0700, Dave Hansen wrote:
> On Wed, 2008-04-02 at 15:55 -0700, Nishanth Aravamudan wrote:
> > On 02.04.2008 [17:04:48 +0900], Paul Mundt wrote:
> > > On Tue, Apr 01, 2008 at 04:26:14PM -0700, Nish Aravamudan wrote:
> > > Sorting out the mess noted by Adrian is pretty trivial with a
> > > HAVE_HUGETLB_PAGE. How about this?
> > 
> > I'm confused, isn't the following simpler fix equivalent?
> > 
> > Fix sh3 build with HUGETLBFS=y. Only SH4 and SH5 actually support
> > HUGETLB_PAGE (which HUGETLBFS depends on).
> > 
> > Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> > 
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index d731282..1981f8e 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -978,7 +978,7 @@ config TMPFS_POSIX_ACL
> >  
> >  config HUGETLBFS
> >  	bool "HugeTLB file system support"
> > -	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > +	depends on X86 || IA64 || PPC64 || SPARC64 || ((CPU_SH4 || CPU_SH5) && MMU) || BROKEN
> 
> Yeah, that's equivalent.  But, you have to draw the line at some point
> on how complex that "depends on" is going to get.  I think you each have
> unique pain tolerances. :)
> 
> Personally, I kinda prefer to break it out per-arch, because that SUPERH
> logic is getting a bit screwy.
> 
> You could also do something like this:
> 
> >  config HUGETLBFS
> >  	bool "HugeTLB file system support"
> > -	depends on X86 || IA64 || PPC64 || SPARC64 || (SUPERH && MMU) || BROKEN
> > +	depends on X86 || IA64 || PPC64 || SPARC64 || SUPERH_HUGETLBFS || BROKEN
> 
> And then:
> 
> config SUPERH_HUGETLBFS
> 	def_bool y
> 	depends on (CPU_SH4 || CPU_SH5) && MMU
> 
> on the arch-specific side.  
> 
SUPERH has the MMU dependence because it's the only one out of that list
of architectures that supports both CONFIG_MMU=y and CONFIG_MMU=n
configurations. The dependence on CONFIG_MMU should be tied in to the
HUGETLBFS dependency directly, which is what my patch did.

The other issue is that the dependencies here are just totally backwards.
the file system has the architecture dependence which enables support for
the hugetlb page feature, while the architectures should simply select
whether they can support the hugetlb pages or not and have the file
system conditionalized on that. A bit more work is needed to have
HUGETLBFS and HUGETLB_PAGE toggling independently of each other without
breaking, but that's certainly the next logical step.