On Sun, 20 Jul 1997 18:46:54 -0700 (PDT) 
 Paul Goyette <paul@whooppee.com> wrote:

 > Actually, what I thought might be possible was to have the individual
 > driver (in my case, grf_mv, the NuBus-board video driver) make a call-back
 > to some (new) routine.  The individual driver needs to map the board's
 > address space into the kernel, so it has the virtual address handy.  If it
 > simply called some routine to stash that address in some globally
 > accessible array (indexed by NuBus slot #).  Then later on I could consult
 > that array to do the reverse translation.

No need to do that... you could put the hooks for keeping this list
into bus_space_map() and bus_space_unmap().

 > BTW, what is the difference between "managed" vs "unmanaged" pages?  Does
 > "managed" imply that the page is possibly paged/swapped out at some time?
 > If so, then I rather doubt that that would work in my situation - just how
 > _could_ you swap out a hardware component?  :)

Managed pages are those that are managed by the VM subsystem.  Hardware
devices, the kernel text/data/bss, and overhead memory used by the pmap
and vm system are examples of pages which are _NOT_ managed.

All managed pages correspond to RAM, and appear on the VM page free list
at some point in their lifetime.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939