On Thu, May 19, 2005 at 09:47:47 +0300, Perfect Stranger wrote: > SYS_open uses calls flip_open to do the (open) job > filp_open calls dentry_open to do the (open) job > dentry_open calls file->f_op->open for the actual open job > i've read in a VFS document that only a few file systems implements the > f_op->open call, so .. this means that the default behaviour of the VFS > is sufficient in some cases .. it least it must increase the usage > counter of the file we want to open .. but i couldn't find the piece of > code that does such a behaviour .. all that is done is looking for the > file wanted to be opened, getting a file descriptor, filling it's > fields, calling f-op->open if defined, and then installing it then it's done > so if f_op->open is not implemented the underlying file system is not > touched while openning a file (except for some calls to read_inode while > the path lookup) > so how could the most file systems do open files without the f_op->open > ? or this is not right and the f_op->open is the only way to do the open > job on the underlying file system ? correct me please There is no other usage count but the dentry refcount. The dentry refcount is incremented in lookup, when a reference is put in the nameidata, and that reference is later moved in struct file, so the refcount is just retained. For mosdt underlying filesystems, concept of open file is useless. Disk filesystem just does the reads and writes and does not care about opens and closes at all. Some network filesystems do care -- and have f-op->open. As for deleting files that have link count 0, deleting files only happens when their struct inode is being freed. struct file has a reference to struct dentry and struct dentry has a reference to struct inode, so the struct inode can't be deallocated while the file is open. That's it. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
