Messages in this thread |  | | | Date | Wed, 6 Feb 2008 10:15:25 +0100 | | From | Ingo Molnar <> | | Subject | Re: [patch 2/3] CONFIG_HIGHPTE vs. sub-page page tables. | |
* Andrew Morton <akpm@linux-foundation.org> 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
|  |