* Andrew Morton <[EMAIL PROTECTED]> 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-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
