Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
> > (2) the struct file+struct dentry+struct inode complex is incredibly heavy
> > for most of what I want to do (though does have advantages);
> Well, all (ok most) of this complexity is to support Unix semantics.
> Adding structures with different sematics will (IMHO) mean huge
> increase in complexity (if interactions are handled correctly) and
> invites bugs
I think we have a misunderstanding here... I meant that using the VFS
structures for Win32 objects like mutexes, semaphores and events is massive
overkill, and uses a great deal of unnecessary memory.
What I did was to have a separate structure for representing Win32 objects
that is kept totally separate from the rest of the Linux kernel VFS stuff. It
is also a lot smaller than the three-layer VFS system, and only has the bits
that are necessary for implementing Win32 object handling and waiting.
Note though, in the case of a file handle, this Win32 object contains a
pointer to a struct file, but this is the only way to gain access to the VFS
through this system, and it still isolates the VFS effectively.
> > (3) Linux file structures do not hold enough information to support
> > CreateFile (access & sharing interactions).
> Any information not in kernel structure is Wine specific anyway, so
> should be separate
Definitely, and I've kept it so.
What I meant on the CreateFile() front is that this function takes an access
bitmask and a share bitmask which interact with other CreateFile()'s and some
other functions. For instance, if two separate CreateFile()'s are issued on a
file then the second is rejected if it's share mask excludes the first's
access mask or if the first's share mask excludes the second's access mask.
It gets a bit more complex as more CreateFile()'s succeed on a particular
file, since the access flags are additive, and the share masks are
subtractive.
The point, though, is that this information must be retained to reproduce the
semantics of the relevant functions. Wine keeps it in the wineserver process,
and uses RPC over sockets to get to it.
> Everybody sometimes gets an idea which looks very promising (and yes, I
> too like my ideas more then the other).
> However, Unix has quite a lot of mechanisms for interprocess
> comunication: signals, shared memory, SYSV IPC semaphores and messages,
> sockets, pipes. A lot of kernel structers and code is just to make
> this work efficiently and relaiably. Putting in the kernel subsystem
> which to large degree has the same functionality (but with incompatible
> interface) seems like a recipe for disaster (small is the project
> dies, big is it makes its way to the kernel).
Why should it be a disaster? It can just be kept as a module that is loaded to
accelerate Wine.
> On construtive grounds: I think that nobody would object putting
> into kernel few primitives if they are critical for Wine performance.
With what API?
> However, I would rather belive that they already exists. As long
> as I understand the main problem is Wine I/O performance. The other
> problem is to have efficient mutexes. I expect SYSV stuff to be
> reasonably efficient, and very fast mutexes may be implemented
> (almost) in user space using ix86 assembly. With shared memory and
> fast mutexes it should be possible to move I/O to client side even
> in multithreading programs.
That entails all sorts of other problems... On Win32, a lot of these objects
are named... That means you have to have some sort of atomic-access name table
in shared memory. And you also have to implement WaitFor*() without doing a
tight polling loop (whilst you could use signals, that is slow). Also you have
to be able to do release-on-death management (how to catch SIGKILL?).
The thing about the kernel is that it has pre-existing services to solve these
problems: locks, wait-queues and atomic counters.
You can solve _most_ of these problems in userspace without a separate server
process, but at the cost of a great deal of extra complexity and at the cost
of not being able to provide the full behaviour.
> I think that Linux programmers rather than new syscalls would like
> Wine to provide ability to handle metafiles (it happened), OLE
> streams or W32 widgets. So, from such a point of view us much
> as possible interfaces should be Unix-like, and W32 interfaces
> used only when needed.
Or maybe, they'd like both to be available. The two aren't mutually exclusive.
> I understand that Wine has good reasons to use W32 interfaces internally,
> but pushing them to Linux kernel seems bad for me.
Don't use it then... it'll not be mandatory. Wine has also to support OS's
that can't or won't add Win32 support in the kernel.
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 23 2000 - 21:00:24 EST