Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Eduardo E. Horvath <eeh@one-o.com>
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" <eeh@one-o.com> 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)
		return(NULL);

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

> 
>  > 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				eeh@one-o.com
	"I need to find a pithy new quote." -- me