Phil Nelson wrote:
> On Sunday 25 March 2007 07:07, u+codalist-p4pg_at_chalmers.se wrote:
>> This would probably work well for systems without mmap(),
>> it is what you meant with "OS-specific"?
>>
>> Otherwise I fear that we'd miss possible modifications done via mmap().
>> It may be used though as another "shortcut" check if there were no mmap()s.
> 
> On the systems that support mmap(), we can check the protection argument 
> for the flag PROT_WRITE.  If it is mapped with write, the kernel module would
> have to assume a write.  (I don't think we want to try to walk the buffer
> cache in each supported system trying to find out if any of the pages were
> modified.)
> 

At least on Linux, the kernel maps all writable pages as read-only. When
a user writes to such a page, the kernel takes the fault and remaps as
read-write. Once the dirty page is cleaned, the page is remapped back to
read-only. It is through this mechanism that writes via mmap can be
detected.


For the Linux coda module, I think this could be implemented with just
a bit of difficulty.

1. Add a "was this ever written?" flag into the code_inode_info struct,
   and a spot to hold the host file's vma->vm_ops.page_mkwrite pointer.

2. Devise a mechanism for getting the coda_inode from a corresponding
   vma. Note that this only needs to remember inodes that have
   a read-write mmap and have not yet been written to.

3. Write the coda_page_mkwrite function in some way like this:

static int coda_page_mkwrite(struct vm_area_struct *vma, struct page *page)
{
	/* TODO: get coda_inode from host vma */
	struct coda_inode_info *cii = ITOC(coda_inode);

	/* TODO: set "written" flag in cii */
	/* TODO: reset the host vma's vm_ops back 
	   since we don't need to be called again */

	if (host vma's page_mkwrite exists) {
		call it and return its value
	} else {
		return 0;
	}
}

4. In coda_file_mmap, do the saving and substitution of coda_page_mkwrite
   in the vm_ops for the vma. Also save the vma to coda_inode mapping.
   This is the most fragile piece of the puzzle, since we have no way of
   knowing if our vm_ops is replaced by someone else later.
   Making sure this can be done reliably is the hardest part of this.




Adam