> rev 1.29 of pmap.c causes me to die....mmu fault...I can't track
> it down at the moment (other commitments)- 1.28 seems to work.

1.29 is Bogus.


I'd sent some mail to jason commenting on various aspects of the
recent pmap changes, suggesting further cleanup.

In particular, I said, about a comment in pmap.c:

>> /*
>>  *	Manages physical address maps.
>>  *
>>  *	In addition to hardware address maps, this
>>  *	module is called upon to provide software-use-only
>>  *	maps which may or may not be stored in the same
>>  *	form as hardware maps.  These pseudo-maps are
>>  *	used to store intermediate results from copy
>>  *	operations to and from address spaces.
>
>Can this paragraph be nuked.  Especially with PMAP_NEW, it's no longer true.

The former sentence really was a question, and "Especially" was
confusing.  With PMAP_NEW, that comment is _definitely_ no longer
true; there are no software maps (at least, no software maps exposed
to the pmap code).  The comment didn't ring particularly true to me
for the current code, either, and so i was just asking if the comment
could be nuked yet.  (Once PMAP_NEW is the default, it definitely can
be.)

I might have mentioned later in my mail about NULL pmaps (software
only maps) not being possible if PMAP_NEW/UVM, but if so I can't find it.

Anyway, (not having talked to him) it would seem that jason took this
as "nuke all the NULL pmap (software only map) stuff in the pmap
module," which is incorrect.

Amusingly (to me, at least) when i got in and read my e-mail, i
noticed his commit message, and sent him mail about it indicating that
it sounded ... wrong.  Then I read further into my mail, and saw your
meesage...  8-)

Anyway, i've reverted pmap.c back to 1.28.


(BTW, inspecting the code and the i386 port's config files, it looks
like PMAP_NEW must be used only with UVM.  Other ports config files
make that clear.  The Alpha port's don't.)


chris