Subject: Re: CVS commit: src
To: Jonathan Stone <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 12/05/1998 18:08:15
On Sat, 05 Dec 1998 15:48:51 -0800
Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
> Thanks, Jason. Tha twill be done. But in general, its a godo rule to
> ``please DOCUMENT interfaces, if you change them, and you want people
> to follow them.''
IT WAS NEVER CHANGED! This is the way it's been since, like, day one for
NEtBSD. Geez, just take a look at like every other known-to-work-properly
pmap in the tree, and see what it does with the page attributes when mappings
are removed. Go ahead and start with the hp300 pmap, which is the one I
cited in my previous mail. Heck, or even the Alpha pmap... note it doesn't
synchronize the mod/ref bits, because there is no hardware support for
them...but also note how it doesn't clear the attributes in
Actually, I'll even paste the relevant code from the hp300 pmap:
pmap_remove_mapping(pmap, va, pte, flags)
* Invalidate the PTE after saving the reference modify info.
if (pmapdebug & PDB_REMOVE)
printf("remove: invalidating pte at %p\n", pte);
bits = *pte & (PG_U|PG_M);
*pte = PG_NV;
* Update saved attributes for managed page
*pa_to_attribute(pa) |= bits;
> As of last month there were 3 ports in our tree doing something rather
> different. And (iirc) the original Mach documentation says something
> rather different...
The 3 ports were... lessee... i386, mips, vax? Charles pointed out the
vax was buggy... and we could observe that the mips was buggy.
Did you bother to check the other 18 or so to see what they did? I'm
guessing the answer is "no" since you didn't note the hp300 behavior
in any of your posts. FYI, none of the hp300-derived pmaps have the
reported buggy behavior wrt. dirty pages.
Quite honestly, I don't really care what the original Mach documentation
says :-) Who knows what might have changed when it was ported to BSD. And
since the hp300 port was like the main 4.4BSD platform, it's usually an
OK idea to see what it does in terms of interaction with the VM system.
BTW, going back to your previous comment wrt. frobbing PG_CLEAN directly...
That can't work on system which actually have hardware mod/ref support,
like the Motorola MMUs. "How is the MMU supposed to change PG_CLEAN?"
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 650 940 5942