"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/
This archive was generated by hypermail 2b29 : Sat Sep 30 2000 - 21:00:14 EST