Re: [Qemu-devel] Qemu: darwine flavour or bellard flavour?; darwine-qemu-fast?; darwine-wine-ppc+darwine-qemu-x86?

[Fabrice Bellard <fabrice@bellard.org>]

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)?
> 
> http://www.winehq.com/site/docs/wine-faq/index#INTEGRATE-AN-X86-EMULATOR

You should add an automatic stub code generator which generates code to 
swap the arguments for all wine entry points.

Fabrice.