David Woodhouse wrote:
> > However, it is probably easier to use the host's, than to write the
> > equivalent (basically duplicating the kernel's futex code in qemu, the
> > hashed locks and wait queues etc.).
>
> The kernel's implementation is a _whole_ lot more complicated than ours
> needs to b
> > On the other hand, using the host's makes it hard to run Linux guest
> > binaries on non-Linux hosts (those which don't have futex), or newer
> > Linux guest binaries on older Linux hosts which have fewer futex ops,
> > or none at all.
>
> I don't think we care. You can't run qemu-i386 on a non
On Thu, 2006-12-14 at 02:16 +, Jamie Lokier wrote:
> David Woodhouse wrote:
> > - sys_futex():
> >
> > We have to translate these into calls to the host's sys_futex() anyway.
>
> I don't think it's necessary to translate to the host's sys_futex(),
> unless the guest will be doing futex operat
David Woodhouse wrote:
> - sys_futex():
>
> We have to translate these into calls to the host's sys_futex() anyway.
I don't think it's necessary to translate to the host's sys_futex(),
unless the guest will be doing futex operations on memory which the
host _also_ does futex operations on.
CLONE
Paul Brook wrote:
- 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 t
> - 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 kern
On Wed, 2006-12-13 at 17:42 +, 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 syscal
On Wednesday 13 December 2006 17:32, David Woodhouse wrote:
> On Wed, 2006-12-13 at 17:22 +, Paul Brook wrote:
> > I've a nasty feeling you're going to break the host libc if you do
> > threading this way. One possibly solution is to use the pthreads API
> > instead, and map everything onto tha
David Woodhouse wrote:
> On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
> > A small request, if you are willing to do it though I think this patch
> > is
> > really useful (IIRC NPTL is a long time trouble with qemu-i386), so instead
> > of leaving this patch just archieved inside
On Wed, 2006-12-13 at 17:22 +, Paul Brook wrote:
> I've a nasty feeling you're going to break the host libc if you do threading
> this way. One possibly solution is to use the pthreads API instead, and map
> everything onto that.
Qemu doesn't use the host's threading support, does it?
--
On Wednesday 13 December 2006 17:01, David Woodhouse wrote:
> On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
> > A small request, if you are willing to do it though I think this
> > patch is really useful (IIRC NPTL is a long time trouble with qemu-i386),
> > so instead of leaving th
On Wed, 2006-12-13 at 23:02 +0700, Mulyadi Santosa wrote:
> A small request, if you are willing to do it though I think this patch is
> really useful (IIRC NPTL is a long time trouble with qemu-i386), so instead
> of leaving this patch just archieved inside qemu-devel, could you please post
Hi David...
> I started playing with nspluginwrapper -- and finally got annoyed with
> the fact that not even /bin/echo from current i386 userspace will run in
> qemu-i386 any more. So I had a go at implementing set_thread_area, futex
> and set_tid_address.
A small request, if you are willing to
I started playing with nspluginwrapper -- and finally got annoyed with
the fact that not even /bin/echo from current i386 userspace will run in
qemu-i386 any more. So I had a go at implementing set_thread_area, futex
and set_tid_address.
Some of the more esoteric futex ops aren't going to work cro
14 matches
Mail list logo
