[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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.
Main Index |
Thread Index |