Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <firstname.lastname@example.org>
From: Eduardo E. Horvath <email@example.com>
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" <firstname.lastname@example.org> 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
Eduardo Horvath email@example.com
"I need to find a pithy new quote." -- me