Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Mon, 25 Sep 2000 13:24:43 +0100 | From | David Howells <> |
| |
"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote: > #define HANDLE_TO_FD(x) ((x)>>2) > #define FD_TO_HANDLE(x) ((x)<<2)
(not quite as simple as that since fd 0 is valid and handle 0 is not, but that's a very minor issue.)
I'm still not keen on the idea, though... One of the things I'm trying to avoid is having to maintain a large patch to the kernel. I've done it before with the configuration manager I wrote. At the time, there was a new version of the kernel out at least once a week, and I spent nearly all my time porting the patch to the latest kernels.
I can see your point... though it could get very heavy on fd's. There are some advantages to the fd approach:
* You could use WaitFor*() on ordinary fds. It could use the internal poll method for non-Win32 fds.
* The /proc/*/fd/ driver could be modified to support Win32 handles, probably by extending the file_operations or inode_operations struct.
* The dentry stuff has filename support.
* Object retension is managed by the VFS.
* No need for kernel based fd<->handle translation.
* You could make the Win32 objects appear in the normal UNIX VFS view of the world by having a new filesystem mounted somewhere appropriate.
Also some disadvantages:
* The VFS is quite heavy on kernel memory: three layers of structure - file, dentry and inode. The inode structure being a bit of a monster.
* The dentry filename support does not handle anonymous files.
* The dentry filename support does not handle separate namespaces.
* Can't pass initialisation data to the open routine.
* Win32 access/share flags would have to be retained in the file struct, and the inode struct would have to maintain a list of these.
* A file handle's view of the filename shouldn't get changed even if the file is renamed whilst open.
And some problems either way:
* The dentry filename support does not handle wide character names or case-independent matching.
One other thing: the idea you put forth about looking at /proc/12345/fd/ could be kept, but as /proc/12345/handles instead with a non-fd approach.
David Howells - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |