lkml.org 
[lkml]   [2007]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/4] x86: unify pgtable*.h
Ingo Molnar wrote:
> * Jeremy Fitzhardinge <jeremy@goop.org> 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


\
 
 \ /
  Last update: 2007-12-14 16:55    [W:0.048 / U:0.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site