Messages in this thread |  | | From | "Albert D. Cahalan" <> | Subject | Re: [RFC] Wine speedup through kernel module | Date | Thu, 21 Sep 2000 10:42:42 -0400 (EDT) |
| |
David Howells writes: > Waldek Hebisch <hebisch@math.uni.wroc.pl> wrote:
> 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.
In spite of that, it should be considered. It allows this:
$ ls -log /proc/self/fd total 0 lrwx------ 1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 3 -> mutex:[720429] lrwx------ 1 acahalan 64 Sep 21 09:12 4 -> event:[592] lr-x------ 1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd
Alternately, it allows this:
$ ls -log /proc/self/fd total 0 lrwx------ 1 acahalan 64 Sep 21 09:12 0 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 1 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 2 -> /dev/pts/4 lrwx------ 1 acahalan 64 Sep 21 09:12 3 -> /mutex/720429 lrwx------ 1 acahalan 64 Sep 21 09:12 4 -> /event/592 lr-x------ 1 acahalan 64 Sep 21 09:12 5 -> /proc/14527/fd $ ls -log /mutex total 0 mrw--w---- 1 acahalan 0 Sep 21 09:33 720429 mrw--w---- 1 acahalan 0 Sep 18 19:33 2852 mrw------- 1 acahalan 0 Sep 21 09:33 53245325 mrw--w---- 1 acahalan 0 Sep 21 09:33 88234 $ ls -log /event total 0 erw------- 1 acahalan 0 Sep 21 09:33 592
>>> (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
It goes into the kernel structure, so that it won't be Wine-specific. SGI has already done this so that Samba would interact properly with regular UNIX software and the NFS server.
(one might support SGI's API for this)
> 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.
Yep, share bits definitely belong in the kernel. How else could you properly protect against regular (clueless) Linux software?
>> 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).
We already have 3 ways to do file locking, so this is only 33% more.
> Why should it be a disaster? It can just be kept as a module > that is loaded to accelerate Wine.
Now THAT would be a disaster. Linux software ought to be able to rely on having these features available. Modules are very bad for this.
Look, we don't have flock() in a module.
>> 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.
Named? That means you use the VFS.
>> 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.
The sendfile() call is mandatory. The real-time schedular and signals are mandatory. The clone() call is mandatory. The prctl() call is mandatory.
See a pattern here? System calls are not supposed to be modular. We shouldn't have calls that appear and disappear on a whim. Binary compatibility requires that system calls be available on all Linux systems.
- 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/
|  |