Subject: Re: mmap() of device
To: Stefan Grefen <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 08/07/1997 03:57:04
On: Thu, 07 Aug 1997 10:20:17 +0200,
Stefan Grefen <firstname.lastname@example.org> 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).
>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.