Re: pmap_mmap

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

On Thu, 18 Nov 2010, Masao Uebayashi wrote:

> On Thu, Nov 18, 2010 at 12:30:52AM +0900, Izumi Tsutsui wrote:

> > > What I ended up is pmap_mmap(9), which is exactly mmmmap(), but
> > > made public.
> > > 
> > > Does this sound right?
> > 
> > Probably it's time to remove "mmap cookie" type as pmap(9) says
> > since we have separate paddr_t and vaddr_t?
> 
> I'm all for rethinking the design from ground.

Yes, this needs to be carefully considered.  The "mmap cookie" is not 
necessarily a PA.  On sparc64 it contains additional information that pmap 
needs to know to successfully set up a correct TLB entry.  And some 
machines, even modern ones, may not have linear physical address spaces.

> And my answer to this question is, bus_space_physload(9).

What's that do and how is that relevent to managed memory?

> cdev_mmap(9) will return "struct vm_physseg *" + "off_t", instead
> of "mmap cookie".  The vm_physseg is either on device's MMIO page
> or RAM.  I hope this will be understood.  Otherwise I have to do
> so many hacks to achieve XIP... :(

I think that will break existing implementations.

Eduardo