David Howells writes:
> 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
Well, if this isn't worth doing right... Patch size is just something
you have to deal with. Hopefully you can get an early-2.5.x merge.
> 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.
Why limit it? If the existing poll method needs extension, do it.
> * 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.
That may be, but we deal with it all the time. The VFS code has to
be well-optimized and SMP-safe. Besides, many of these Win32 handles
will refer to files anyway, won't they?
> * The dentry filename support does not handle anonymous files.
Sure it does. What do you want, pre-deleted files or filesystems
that do not appear anywhere? You can have a filesystem floating
around in free space, sort of half-way mounted (no mount point),
and filled with deleted files with random hex names.
> * The dentry filename support does not handle separate namespaces.
By this you mean...? Can you not just apply a prefix?
Perhaps you could use the half-way mounted filesystems,
with some way to specify the desired filesystem root.
> * Can't pass initialisation data to the open routine.
Well, that would be generally useful for Linux software.
Also useful: an open-read-close operation that doesn't muck around
with fd allocation. Maybe hang the data off of a struct stat, so that
callers can atomicly get everything.
> * 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.
OK. Problem?
The list would be NULL most of the time. If Linux apps start
using this feature a lot, then it can be optimized.
> * A file handle's view of the filename shouldn't get changed
> even if the file is renamed whilst open.
Excuse me? Does Win32 not allow rename of open files?
Assuming that is the problem, you have a few options I think.
You could let handles block rename, except that you might let
root override restrictions caused by non-root users. You could
just ignore this problem and see what, if anything, breaks.
You could lie I suppose, supplying old names as needed.
> And some problems either way:
>
> * The dentry filename support does not handle wide character names or
> case-independent matching.
Yeah, that is a problem. Ignore it, so it might go away. :-)
Mere ASCII case is no problem, and wide characters can always
be translated to UTF-8 to keep the VFS happy. Maybe you can add
an alternate matching function for Win32 and MacOS API support.
> 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.
Doesn't that strike you as being a hack that will cause you
to need _more_ code in the end? You'll end up writing a second
VFS layer if I'm not mistaken.
-
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:15 EST