Re: PAT & pmap(9) changes (was Re: CVS commit: src)

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On Thursday 08 July 2010 15:08:07 Thor Lancelot Simon wrote:
> On Thu, Jul 08, 2010 at 03:03:06PM +0200, Christoph Egger wrote:
> > On Thursday 08 July 2010 14:33:12 Thor Lancelot Simon wrote:
> > > On Thu, Jul 08, 2010 at 12:12:57PM +0200, Christoph Egger wrote:
> > > > > > No comments on this last version.
> > > > >
> > > > > Some of us scarcely have had time to reply to the second version.
> > > > > :-/
> > > >
> > > > It was enough time for code review. I thought, the way how it works
> > > > was clear after the discussion of the first version stopped.
> > >
> > > I didn't see any of the concerns David expressed earlier really
> > > addressed in any way.
> >
> > Please explain. Which concerns were not addressed?
>
> David asked about the interaction of the various mapping registers.  I
> understood his questions to be aimed at producing an abstract, MI
> interface that would result in such MD details being handled behind
> the programmer's back -- the programmer should not have to understand
> this kind of MI detail to write MI code.

Correct.

> The response I saw -- and maybe I missed something -- was a giant table
> of the interaction of these registers as architecturally defined for X86.

His question was x86 specific: He asked how does PAT with MTRR interact,
so he got an x86 specific answer.
I thought he was interested in how does the x86 implementation work.

> That's exactly the kind of detail that people working on MI parts of the
> kernel should never have to encounter.

Correct. That is why the MI flags must be implemented in MD pmap.c
because MI can never know which pagetable bits must be set/cleared.

The four flags were supposed as a proposal in first place and if they don't
fit for any non-x86 port, I expected something like
"PMAP_WRITE_BACK doesn't exist on Sun3" or
"PMAP_WRITE_COMBINE works different on Vax than you describe".
I didn't read anything like this.

Christoph