Re: Introducing non-RAM managed page ("device page")

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Tue, 15 Sep 2009, Masao Uebayashi wrote:

> There are cases where we need to manage addresses of non-RAM devices by MMU.
> One example is XIP, which makes kernel able to execute programs directly from
> memory-mapped NOR FlashROM instead of copying file into RAM.  Others are newer
> video devices (which I'm not familar with).
> 
> UVM allocates a managed page's state (struct vm_page) for each page-sized RAM,
> because its main purpose is "page cache" - cache of on-disk page-sized data.
> OTOH, "device pages" is always volatile.  They're not cache.

I'm curious why you want to get the VM subsystem involved in this process.  
The VM subsystem manages the virtualization of main memory, hence the 
name.  It manages the relationship between non-volatile memory (disk) and 
its temporary cache (RAM).  If you're not backing those non-RAM pages with 
disk then the VM system does not seem to be the appropriate place to do 
that.
  
We've handled mmap()ing device memory forever without getting VM involved.  
Not to imply that the current device mmap() interface could not be 
improved.  What features of the VM subsystem do you think is needed to map 
device pages into processes?

Eduardo