On: Thu, 07 Aug 1997 10:20:17 +0200,
    Stefan Grefen <grefen@hprc.tandem.com> writes:

 >In message <9708061302.ZM13207@picasso.me.ic.ac.uk>  "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).
 >
 >Why? 
 >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
 >table
 >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''.