Re: [Qemu-devel] [PATCH]ish NPTL support.

[David Woodhouse <dwmw2@infradead.org>]

On Wed, 2006-12-13 at 17:42 +0000, Paul Brook wrote:
> Qemu doesn't currently have any real thread support. It has a few hacks that 
> work for simple linuxthreads cases, but I doubt real multithreaded 
> applications will work.
> 
> My point was that instead of blindly passing the threading syscalls through to 
> the host we should consider using the host libc/libpthread thread support. 

Well, let's break things down individually.

- sys_set_thread_area():
- sys_get_thread_area():
- clone(CLONE_SETTLS)

This _is_ handled in qemu, since it's just a case of loading new stuff
into the emulated GDT. (Well, I didn't do get_thread_area but it's
simple).

- sys_futex():

We have to translate these into calls to the host's sys_futex() anyway.
I need to go through the rest of the futex operations and see how many
we can emulate cross-endian, and perhaps add some kernel support to make
the answer "all of them".

- sys_set_tid_address():
- clone(CLONE_CHILD_CLEARTID):

We _could_ manage to do this in qemu for controlled thread exit -- it
would be hard for uncontrolled exit though. But I don't see any harm in
just letting the kernel do it either. I don't mind too much, but if we
can let the kernel do it I'm happier that way.

- clone(CLONE_PARENT_SETTID):
- clone(CLONE_CHILD_SETTID):

We need endianness-mangling on these so we have to get involved somehow.
But I think we do need to use the kernel's support and then marshal the
result back to the guest's memory.

-- 
dwmw2