On 2010-02-18, at 22:42, Aneesh Kumar K.V wrote:
The below set of patches implement open by handle support using
exportfs
operations. This allows user space application to map a file name to
file
handle and later open the file using handle. This should be usable
for userspace NFS and 9P server. XFS already support this with the
ioctls
XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE.
struct file_handle {
int handle_size;
int handle_type;
void *f_handle;
};
What is the required size of the f_handle field? It seems that either
this
should be a well-defined structure size in the header, or the syscall
will return an error like EOVERFLOW if the handle will not fit into
the supplied handle_size, and it returns the required size in
handle_size.
fh.handle_type = 0;
fh.handle = malloc(100);
fh.handle_size = 100/sizeof(int);
It seems strange to define the handle_size in terms of ints instead of
bytes?
ret = syscall(338, argv[1], &fh);
fd = syscall(339, &fh, O_RDONLY);
What is the expected lifespan of "fh" to remain valid in the kernel?
Presumably this is not just the encoding of the inode number into a
buffer, or it would be too easy to forge from userspace. That means
there needs to be some unguessable state in the kernel for each file
handle, that may potentially need to be kept indefinitely if there is
no expiry.
Will "fh" be portable between processes? I assume that is the intent,
but good to declare the actual semantics of the syscalls before they
go into the kernel.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
