Subject: Re: mmap() of device
To: Stefan Grefen <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 08/07/1997 03:57:04
On: Thu, 07 Aug 1997 10:20:17 +0200,
    Stefan Grefen <> writes:

 >In message <>  "Robert Black" wrote:
 >> If you know of any problems I am likely to run into doing this I'd be glad to
 >> hear them. The other way of doing it that I can think of is to write a new MI
 >> pager to handle this sort of thing in a generalised way (it might be possible
 >> to just extend the device pager to add a few extra control hooks).
 >Just invalidate the page(s) and the next page-fault will call mmap again and you
 >can supply a different page. I just haven't checked how well the mmap interface
 >would handle a invalid page here ....
 >There maybe some gotchas there, but i think this will be the most stable and por
 >approach. (over revisions and architectures)

no,  no,  no.

If one takes the approach of writing a d_mmap() entrypoint maps
``normall'' (non-bus) pages into memory, one really only has the
choice of writing a ``pager'' to handle, and refcount, such requests;
or of mapping the pages and never ever ever unmapping them.

The latter works well for non-shared devices like framebuffers,
and fails abysmally for shared devices like network interfaces.

The right answer really is to write a pager that can revoke the mmap()
bindings created by user processes, and re-create them on demand as
the user processes (or a network peer) faults on the pages.

One simply doesn't get enuf info (cgd's reply aside) to do this with a
d_mmap() entrypoint.  The basic gotcha is that the VM system calls the
d_mmap() entrypoint once to ensure the page exists and then once more
to actually map it.  That guarantees that you cannot do refcounting in
a d_mmap() entrypoint.

Like, ``D'oh''.