Messages in this thread | | | From | Jason McMullan <> | Subject | Re: mmap(), close(), and dget() | Date | 3 Feb 1998 23:15:14 GMT |
| |
Bill Hawes <whawes@star.net> wrote with confidence: >> Shouldn't the proper semantics be that unmapping the vma does >> a dput(), sysctl_close() does a dput(), and that dput() itself >> calls inode->op.close() when the use count is zero???
> 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...
| |