lkml.org 
[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC] Wine speedup through kernel module
Date
From

"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/

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