| Age | Commit message (Collapse) | Author |
|---|
|
For some strange (ehmm) reason, only the prototype was wrong. The implementations
were right.
|
|
and arbitrary flags into one argument.
One new flag is PMAP_CANFAIL that tells pmap_enter that it can fail if there
are not enough resources to satisfy the request. If this flag is not passed,
pmap_enter should panic as it should have done before this change (XXX - many
pmaps are still not doing that).
Only i386 and alpha implement CANFAIL for now.
Includes uvm updates from NetBSD.
|
|
The archs that didn't have a proper PMAP_NEW now have a dummy implementation
with wrappers around the old functions.
|
|
|
|
boolean_t pmap_extract(struct pmap *, vaddr_t, paddr_t *).
Matches NetBSD. Tested by various people on various platforms.
|
|
- Change pmap_change_wiring to pmap_unwire because it's only called that way.
- Remove pmap_pageable because it's seldom implemented and when it is, it's
either almost useless or incorrect. The same information is already passed
to the pmap anyway by pmap_enter and pmap_unwire.
|
|
The _pmap_enter kludge only applies to i386.
|
|
|
|
|
|
|
|
the access type that caused this mapping. This is to simplify pmaps
with mod/ref emulation (none for the moment) and in some cases speed
up pmap_is_{referenced,modified}.
At the same time, clean up some mappings that had too high protection.
XXX - the access type is incorrect in old vm, it's only used by uvm and MD code.
The actual use of this in pmap_enter implementations is not in this commit.
|
|
|
|
|
|
|
|
them virtualized
|
|
needs it.
|
|
<chuck@openbsd.org>. This code is as of yet disabled on all platforms,
actually not yet supported on more than mvme68k, although other
platforms are expected soon, as code is already available.
This code makes handling of multiple physical memory regions
consistent over all platforms, as well as keeping the performance of
maintaining a single continuous memory chunk. It is also a
requirement for the upcoming UVM replacement VM system.
What I did in this merge: just declared the pmap_map function in a
MD include file per port that needs it. It's not an exported pmap
interface, says Chuck. It ended up in differnt include files on
differnet ports, as I tried to follow the current policy on a per-arch
basis.
|
|
|
|
|
|
|
|
|
