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 [1] and 9P server [2]. XFS already support this with the ioctls XFS_IOC_PATH_TO_HANDLE and XFS_IOC_OPEN_BY_HANDLE. [1] http://nfs-ganesha.sourceforge.net/ [2] http://lists.gnu.org/archive/html/qemu-devel/2010-03/msg01087.html Changes from v1: a) handle size is now specified in bytes b) returns -EOVERFLOW if the handle size is small c) dropped open_handle syscall and added open_by_handle_at syscall open_by_handle_at takes mount_fd as the directory fd of the mount point containing the file e) handle will only be unique in a given file system. So for an NFS server exporting multiple file system, NFS server will have to internally track the mount point to which a file handle belongs to. We should be able to do it much easily than expecting kernel to give a system wide unique file handle. System wide unique file handle would need much larger changes to the exportfs or VFS interface and I was not sure whether we really need to do that in the kernel or in the user space f) open_handle_at now only check for DAC_OVERRIDE capability Example program: ------------- cc -D_GNU_SOURCE <src.c> ---------------- #include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> #include <sys/types.h> #include <sys/stat.h> struct file_handle { int handle_size; int handle_type; void *handle; }; int main(int argc, char *argv[]) { int ret; int fd, dirfd; char buf[100]; struct file_handle fh; fh.handle_type = 0; fh.handle = malloc(100); fh.handle_size = 100; errno = 0; ret = syscall(338, argv[1], &fh); if (ret) { perror("Error:"); exit(1); } dirfd = open("/", O_RDONLY|O_DIRECTORY); fd = syscall(339, dirfd, &fh, O_RDONLY); if (fd <= 0 ) { perror("Error:"); exit(1); } memset(buf, 0 , 100); while (read(fd, buf, 100) > 0) { printf("%s", buf); memset(buf, 0 , 100); } return 0; } -- 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
