* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: > > > urgh, well, thanks for trying. If there's significant risk factor > > > (or hassle) in fixing the macros then I'd suggest we not do it for > > > now - it's a separate project. > > > > I'm still at it. I does make sense to convert the damn macros to > > inline functions. The question now is the order of things, the macro > > cleanup first or the sub-page page tables first? I would prefer the > > sub-page page tables first since that code has been hanging around > > in -mm for a while and could go upstream after I regenerated the > > patch and test compiled it again. We do need it for KVM and we want > > to push our KVM patches for s390 soon. > > I'd suggest do the macro ceanup later. That's the sort of thing which > we can/should trickle through arch maintainers. note that there are ways to stage even API extensions like adding an extra 'struct mm_struct *mm' to macros. It takes a temporary ugliness like: #define __EXTRA_MM_ARG_DEF , struct mm_struct *mm #define __EXTRA_MM_ARG_VAL(arg) , (arg) which converted architectures redefine. and at the end eliminate these compatibility macros from the core, once all arches have converted. so we _could_ stage even something like this. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
