tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pmap_mmap


On Thu, Nov 18, 2010 at 12:30:52AM +0900, Izumi Tsutsui wrote:
> > md(4) mmap has to return "mdpgno" of char md_root_image[].  I can
> > get physical address of md_root_image[] by pmap_extract(9).  There's
> > no API to convert physical address to "mdpgno" (opposite of
> > pmap_phys_address(9)).
> Well, there is awful implementation in sys/dev/usb/udl.c.

Can't udl.c (ab)use bus_dmamem_alloc(9) and bus_dmamem_mmap(9)?
Even if the allocated memory is touched only by user programs,
I think it's somewhat better than exposing kernel wired memory.

md(4)'s case is a little different, because md_root_image[] is
static (kernel .data).

> > 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.

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

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... :(

> >>    paddr_t pmap_phys_address(paddr_t cookie)
>  :
> >>            The existence of this function is highly dubious, and it is
> >>            expected that this function will be removed from the pmap
> >>            API in a future release of NetBSD.
> ---
> Izumi Tsutsui

Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635

Home | Main Index | Thread Index | Old Index