Ingo Molnar wrote:
> * Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>
>> All x86 modes and architectures have very similar pagetable
>> structures: the page flags, the accessors for testing/setting them,
>> and the combinations of page flags used for kernel and usermode
>> mappings are all the same. The main difference is between 32 and
>> 64-bit pagetable entries, with the latter supporting the NX bit.
>>
>> The most significant difference between the modes/architectures is the
>> number of levels in the pagetable (4 for 64-bit, 3 for 32-bit/PAE, 2
>> for non-PAE 32-bit). This accounts for the remaining code in the
>> various mode-specific headers.
>>
>> I've tried to avoid changing formatting as much as possible, so that
>> the code motion is more obvious. A subsequent patch will clean things
>> up in place.
>>
>
> the dreaded auto-qa - this patch fails to build:
>
> arch/x86/mm/init_32.c: In function 'mark_rodata_ro':
> arch/x86/mm/init_32.c:811: error: 'PAGE_KERNEL_RX' undeclared (first use in
> this function)
> arch/x86/mm/init_32.c:811: error: (Each undeclared identifier is reported
> only once
> arch/x86/mm/init_32.c:811: error: for each function it appears in.)
> make[1]: *** [arch/x86/mm/init_32.o] Error 1
>
Sigh. Shouldn't be too hard to deal with.
> config attached. I'll skip this series of your patches for now. I'd
> expect this to be one of the hardest areas to unify - it's one of the
> areas with the largest amount of arbitrary deviations between 32-bit and
> 64-bit and these include files permeate everything.
>
Yeah, it's been great fun :(. On the other hand, I think its getting
there; the interactions between the various headers is getting more
comprehensible, and moving to a consistent use of inline functions
rather than a mixture of macros and inlines is making things more
deterministic.
> ( In case you are thinking about approaching this differently, i'd
> suggest a strategy that doesnt just try to unify the whole kit at once
> but does it with very small steps where each step is trivially
> verifyable. 50 small patches are generally a lot easier to create than
> 5 big patches. [ Of course if you can do 5 perfect patches that's just
> as good :-) ] )
>
Yeah, I tried doing it in smaller pieces, but its fairly difficult just
because its all so inter-tangled. But I think its close now.
J
--
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/
