lkml.org 
[lkml]   [1998]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Suggested changes to the VFS
From
Date
>>>>> "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

\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.071 / U:0.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site