Andi Kleen <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
