* Martin Schwidefsky <schwidefsky@xxxxxxxxxx> wrote: > > > include/asm-sh/hugetlb.h | 28 +++++++++++++++++++++++++ > > > include/asm-sparc64/hugetlb.h | 30 +++++++++++++++++++++++++++ > > > include/asm-x86/hugetlb.h | 28 +++++++++++++++++++++++++ > > > > these seem largely duplicated - shouldnt there be an > > asm-generic/hugetlb.h instead, which asm/hugetlb.h could include to > > get default behavior? It would probably reduce the linecount of your > > patch as well. > > Well the hugetlbfs primitives are architecture specific, aren't they? > Just like the other page table manipulation functions. I find the > usual method to use asm-generic/<xxx> and a lot of defines and #ifdefs > to pick up the correct definition from a generic header file rather > hard to read. In the end each arch that wants to use hugetlbfs has to > define each of the hugetlb primitives. Most of them are rather simple, > e.g. the x86 set_huge_pte_at is just a set_pte_at. One line to define > the primitive. Now we could have an #ifdef block around the default > definition that maps set_huge_pte_at to set_pte_at in asm-generic and > an ARCH_HAS_xx override for architecture that need to do something > more complicated. Somehow that was where we started .. I think the > best way to get rid of the ARCH_HAS_xxx fugliness is to let each > architecture define their primitives, even if it looks like code > duplication. sorry, i misread your patch - it indeed looks cleaner with your patch applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
