> The inode i_op functions operate at a higher level, when there's still a file
> pointer around. Unmapping a vma does indeed do a dput() but the file pointer
> used for mapping the vma is long gone.
Ok. Let me get this straight (pull out kernel headers):
According to <linux/dcache.h>, a dentry has a d_inode
pointer. All well and good.
And it looks like <linux/fs.h> tells me that a) an
inode contains a list of the dentries that point to it and
b) i_op functions that operate on a `modify filesystem
and get data from it' level. I now understand what you're
telling me.
Ahhh - enlightement from <linux/mm.h>!
<BUZZWORD>Paradigm shift!</BUZZORD>. Now if only this
had been documented:
"Linux's file_operations->mmap() should be considered
a `gate' into the vm_area_struct, similar to libc's open()
versus the kernel file_operations->open(). After the initial
mmap(), the file * and the vm_area_struct * should be considered
LOGICALLY DISTINCT entities, and you MUST take into account
that the file_operations->close() and vm_operations_struct->close()
have _NOTHING_ do to with each other. "
Do I have it right now?
-- Jason McMullan - Linux - GGI - http://beans.visus.com/~jmcc NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground...