Messages in this thread |  | | Subject | Re: [RFC] Wine speedup through kernel module | Date | Thu, 07 Sep 2000 14:28:36 +0100 | From | David Howells <> |
| |
Andi Kleen <ak@suse.de> wrote: > It could use a read-only-to-clients shared memory with some locking tricks.
You still have to be able to emulate WaitForMultipleObjects() which I think is quite difficult from userspace. It can perhaps be done with signals, but that then incurs costs in invoking signal handlers. And however it is done, it would require thread-safe wait queues to be implemented in userspace.
The kernel's wait queues make this a lot easier, quicker and safer.
> I looked a bit over the code. Your Mutex classes do not look very SMP safe, > have they been tested with SMP ?
Look carefully... It uses the atomic bit set/clear functions to modify the state, and the wait-queue carries its own lock.
And yes, they have been SMP tested... I have a dual Pentium-II box at home. I ran my five-thread test programs on it and they ran extremely fast without crashing (faster than Win2000 on the same box with the same test).
> Also I guess it would be better to implement Mutexes in user space as far as > possible and only use kernel help for inter process mutexes.
What's the difference? And how do you tell that a mutex is going to be used only between threads and not between processes? Anonymous mutexes don't actually help - think of DuplicateHandle!
Plus it only greatly complicates your WaitFor* functions.
> For the object name management I did not found any limits that would prevent > an user from allocating all memory. Are there any?
getname() implies MAXPATHLEN (the VFS name to kernel-space function).
> wineserver_read is definitely buggy, it holds spinlocks while calling > functions that may sleep (e.g. the copy_to_user in wineserver_read_printf)
Good point.
> Overall it does not look too bad. It would be nice though if there was an > easy way to extend the object management from user space, because Windows > probably has a lot of object types Linux definitely does not want in kernel > space.
There will be... though there aren't actually all that many "kernel" object handles... most of what are called "handles" are really just userspace object handles issued by userspace DLL's.
However... for instance, the way I'm planning on implementing the registry through this module is to have a cut down RPC server (using the RPC mechanism available in that module) that gets invoked implicitly by RegOpenKey, et al.
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/
|  |