[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu
Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?
Wed, 09 Jun 2004 21:48:03 +0200
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
John Davidorff Pell wrote:
I was just thinking about this: It might be a good idea to CC all posts
to this list to the main qemu list, so that a) we can get more feedback
b) we can be more visible to other qemu maintainers b) fabrice sees that
he should help out in the port to MacOSX (Which is likely the best way
to get it running and happy). :-)
Also, those of you working on darwine-qemu seem to be focusing only on
the system-emulation, not on the user-mode emulation (qemu-fast).
You mean qemu-i386 ?
Personally, I would *really* really *really* like user-mode emulation on
MacOSX (but i'm not actually working on code, so I can't complain too
much). I would think that it would make communication between
darwine-wine and darwine-qemu easier if both were in the same space,
instead of one thinking its on/is its own system.
User mode emulation with qemu-i386 is not interesting for the darwine
project. You should concentrate in using libqemu in wine. Look at the
example in qemu/tests/qruncom.c.
Lastly, I was thinking about how darwine is going to actually use x86
code from qemu in ppc code from wine. I think that making the user-mode
emulation work might allow special hooks to be added into the
darwine-qemu-fast so that the wine API can be called much like the
syscalls are translated (or would be translated). Endianness is an
issue, but if all is called from x86 code, can we trick it by just
keeping it little-endian (or am I just being stupid)?
You should add an automatic stub code generator which generates code to
swap the arguments for all wine entry points.