"Albert D. Cahalan" <acahalan@cs.uml.edu> wrote:
> 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 wouldn't like to bet on it.
> Why limit it? If the existing poll method needs extension, do it.
I suppose so. On a separate issue, the more I look at the poll and select
implementation, the more I'm convinced there's a leak, but I'm not sure it
matters.
> 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?
Run HandleEx sometime... most of the handles are generally not files,
particularly for a program that uses the perfmon stuff, when it uses heaps of
registry handles and section handles.
> > * 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.
Actually, I suppose could look at how /proc does things. Make anonymous
objects just numbered files in a special directory.
> Well, that would be generally useful for Linux software.
But hard to achieve at the moment... Not only would the VFS have to change,
but all the filesystems too.
> 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.
Better still, just give the syscall a filename, a buffer and a buffer size.
> > * 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?
Not a nice thing to add. Care has been taken to decouple the file from the
inode (a dentry sandwich). Also it means more maintanence work on the part of
the VFS.
Care would also have to be taken to avoid a reference count loop: File points
to Inode points to File. Not insurmountable though.
> The list would be NULL most of the time. If Linux apps start
> using this feature a lot, then it can be optimized.
No. The list could never be NULL.
> Excuse me? Does Win32 not allow rename of open files?
It does, but the internal object name does not change. You cannot create a new
file of the old name whilst it is still open internally.
> 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.
*shiver*
> You could just ignore this problem and see what, if anything, breaks.
I really don't like doing that. It's always an important customer who falls
over it.
> You could lie I suppose, supplying old names as needed.
Then you should stick with the current system.
> Doesn't that strike you as being a hack that will cause you
> to need _more_ code in the end?
No.
> You'll end up writing a second VFS layer if I'm not mistaken.
No I won't. I wasn't really thinking in terms of having a process handles map
as a directory full of fd's, more like a flat file with a list in it.
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:17 EST