Messages in this thread | | | Subject | Re: Suggested changes to the VFS | From | (Eric W. Biederman) | Date | 24 Mar 1998 13:06:26 -0600 |
| |
>>>>> "HA" == H Peter Anvin <hpa@transmeta.com> writes:
HA> I would like to make the following changes against the VFS interface HA> in 2.1, and I would very much appreciate your comments (just exactly HA> what have I overlooked):
HA> open: HA> The individual filesystems would be responsible for allocating HA> a file structure pointer and return it; a canned function HA> would be available that would perform the equivalent of the HA> current code in do_open (and, of course, this would still be HA> performed equivalently for inodes which have NULL in their HA> open fields.) This would allow the filesystems to return HA> something other than a newly created file pointer. This could HA> include a socket, a pipe, or a dup of an existing file HA> pointer.
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?
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |