Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <>
From: Eduardo E. Horvath <>
List: tech-kern
Date: 03/06/1999 12:36:25
On Sat, 6 Mar 1999, Jason Thorpe wrote:

> On Sat, 6 Mar 1999 07:49:26 -0800 (PST) 
>  "Eduardo E. Horvath" <> wrote:
>  > And it immediately calls pmap_enter() if the mapping would succeed.  There
>  > is no instance I can find where if the d_mmap() routine is called and
>  > returns a success, pmap_enter is not immediately called.  I see no other
>  > calls just to check for permissions.
> BZZT :-)
> That's the FAULT handler you're looking at.
> Now, take a look udv_attach().

I looked there.  All I see is:

	mapfn = cdevsw[major(device)].d_mmap;
	if (mapfn == NULL ||
			mapfn == (int (*) __P((dev_t, int, int))) enodev
			mapfn == (int (*) __P((dev_t, int, int))) nullop)

Never seems to call the function, just checks to see if it's a valid

>  > That would also work.  Probably good to have it called for unmapping
>  > (pmap_remove()) so the driver (and bus_space*()) can free up any resources
>  > they may have needed to allocate for the mapping.
> No, not pmap_remove(), but rather when the device is munmap'd (this is
> a different operation).

Arguably, if the process is swapped out the driver could reallocate
whatever resources it's using until it's swapped back in and the mappings
are restored.

Eduardo Horvath
	"I need to find a pithy new quote." -- me