• DeviceDriverMmap

<bronaugh> if you're using mmap on a file descriptor, how are the changes eventually written to disk? what gets called?
<bronaugh> does the normal read/write function eventually get called?
<riel> bronaugh: two times
<riel> bronaugh: changes are written to disk either at/after msync(2) time, or after munmap(2) time
<riel> bronaugh: or, if the system has a memory shortage, by the pageout code
<bronaugh> alright. and that uses the normal read/write calls?
<rene> but I believe he means if the actual sys_read() / sys_write() code ie getting called. to that, no, the actual "dirty" pages are written
<riel> bronaugh: no
<rene> (s/ie/is/)
<riel> bronaugh: data changed through mmap does not go through read/write syscalls
<bronaugh> ok. here's why I'm asking.
<bronaugh> I'm modifying framebuffer code for some nefarious purposes. I don't want a memory-backed framebuffer; I want all calls like that to go over the network.
<bronaugh> now, framebuffers have an fb_read and an fb_write call associated with them. these end up being called in fbmem.c by the main handler for read and write, which is set up in the file_operation struct.
<bronaugh> my question is -- will those routines be called?
<bronaugh> (given that they will be called normally by a read/write system call)
<-- SGH has quit (Quit: Client exiting)
<bronaugh> sorry if I might be a bit confusing here.. just trying to get a handle on it myself
<riel> if you set those routines as the mmap read and write functions, yes
<bronaugh> ohh, special functions. ok.
<bronaugh> I'll dig into that.
<riel> you can set them at mmap(2) time
<bronaugh> ok, so how does one do that?
<bronaugh> (set the mmap read and write functions)
<riel> lets take a look at drivers/video/skeletonfb.c
<riel> static struct fb_ops xxxfb_ops = {
<bronaugh> alright.
<bronaugh> wish I'd looked at that. heh.
<riel> you can see it set .fb_read and .fb_write and .fb_mmap functions ?
<bronaugh> yup.
<bronaugh> I've set those up in my driver.
<bronaugh> they're stubbed but present.
<riel> wait, I forgot something important that is device driver specific
<riel> on a frame buffer, you want writes to show up on the screen immediately
<riel> you don't want to wait on msync() for your changes to hit the screen
<bronaugh> yeah.
<bronaugh> but this is a network framebuffer, so batching up writes is a plus.
<bronaugh> though you don't want to go -too- far with that.
<bronaugh> we'll just say it's a normal framebuffer as a simplifying assumption.
<bronaugh> normal but remote
<bronaugh> (ie, not in the same memory space)
<riel> one thing you could do every once in a while is initiate the msync from kernel space
<riel> not the cheapest thing to do, but ...
<bronaugh> it'd work in a pinch.
<riel> easy to verify the functionality, transparently to userspace