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@xxxxxxxxxx> 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@xxxxxxxxxx>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/