vfs: is there any way to distinguish read() for different file descriptors
vfs: is there any way to distinguish read() for different file descriptors
- Subject: vfs: is there any way to distinguish read() for different file descriptors
- From: Anatol Pomozov <email@hidden>
- Date: Mon, 30 Jan 2012 16:33:33 -0800
Hi,
I am working on fuse filesystem kernel extension (
http://fuse4x.org). Fuse originates from linux and follows its vfs semantics.
One of the difference between Linux and XNU vfs is that some operations on Linux (e.g. open, close, read, write, ) have access to "file" structure. This structure contains information about file descriptors and it is possible to distinguish if these operations are run against different descriptors.
int fd1 = open("a",..) // fuse userspace generated FD_1
int fd2 = open("a",..) // fuse userspace generated FD_2
read(fd1,..) // fuse userspace receives FD_1
read(fd2,..) // fuse userspace receives FD_2
Fuse userspace filesystem generates a unique id for every open() and stores this id in "struct file" private data. Later the id is passed on every read/write operation.
Now I need to do something similar for XNU. In its code VNOP_READ does not have access to anything like file structure.
Is there any way to distinguish if operations (read/write/..) are run against different descriptors? Currently fuse4x does an ugly hack - it stores 3 descriptors per vnode - for read-only/write-only/rdrw descriptors. It means if the same file is open 2 times with there same mode (e.g. RDONLY) then fuse4x uses only one file descriptor. For fuse userspace it looks like the file was opened only once and all read operations are done for the same file descriptor.
I would like to make it better. Is there any way to distinguish vnop operations for different file descriptors? Should I add a map (process_id,mode)->fd to vnode? It does not solve the problem completely, but at least 2 different processes will have different fd numbers for the same file.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden