Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: Suggested changes to the VFS | Date | Tue, 24 Mar 1998 12:57:01 -0800 (PST) |
| |
> There are two parts to the open process. Getting the dentry and inode > with lookup, which can do everything you want. And opening a file > descriptor, which provides a nice handle for the file. The later case > is what open is for. > > Currently I use open to reserve storage via struct file f_private_data > to hold my place (in non-linear directory files). And release is what > I use to release that storage. > > HA> Incidentally, open is defined as a file_operation, which IMO > HA> is bogus, since you can only open() an inode, and the open > HA> function is passed an inode anyway. It would appear more > HA> logical to me to move open to the inode_operations structure. > > Perhaps it's the name that's bogus and misleading?
No, I don't think so. Your message doesn't really parse to me, so maybe I'm misunderstanding, but it seems very weird that open() is considered a file descriptor operation when it is fundamentally a constructor for a file descriptor. Incidentally, open() *always* gets its file descriptor operation from the inode operations immediately before calling it.
I think open should be allowed to return a reference to an already existing file descriptor if it wants to; it doesn't seem that major of a change if a canned routine is provided to do what the pre-open initialization code does.
-hpa
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |