On Thu, 4 Mar 1999, Jason Thorpe wrote:

> On Thu, 4 Mar 1999 22:22:00 +0100 (MET) 
>  Anders Magnusson <ragge@ludd.luth.se> wrote:
> 
>  > Not likely :-) but maybe the page tables that maps the framebuffer
>  > gets paged out. 
> 
> Well, more like devices aren't really "wired" memory.  The pmap is allowed
> to forget those mappings at any time, as it sees fit.
> 
> Say, for example, a process which has mapped the frame buffers is _swapped_
> out.  The Alpha pmap will then free all of its page tables.  You need to be
> able to reestablish the mapping for individual pages later, when that process
> runs again.

So the concept is that it is better for the VM layer to remember keep some
strangely encoded cookie and pass it to pmap_enter() (which expects a
physical address BTW) than to call the device routine again to map the
framebuffer back in?  

Now I suppose we could say that that's why I separated vm_offset_t into
vaddr_t and paddr_t, so the paddr_t could be some funny structure
containing both the physical address and some additional information
describing the address space it's in, its cache attributes, endianness,
and range.  But isn't this going a bit overboard?  I would presume that
the only part of this information that changes for managed pages is the
physical address.

Or would this go into the bus_space_handle_t and we'd use the paddr_t to
encode just the physical address?  Then we need to change pmap_enter() to
take a bus_space_handle_t, and the VM subsystem needs to call some routine
to convert from a paddr_t to a bus_space_handle_t.

Either of these schemes should be workable if there were some sort of
elegance in the design.  But from an efficiency perspective it must be
simpler in most instances to have the device (*d_map)() routine map the
page in directly rather than encode all the extra information into a
paddr_t and have pmap_enter() decode it every time it maps in a page.

=========================================================================
Eduardo Horvath				eeh@one-o.com
	"I need to find a pithy new quote." -- me