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

[Pierre d'Herbemont]

Le 9 juin 04, à 08:09, John Davidorff Pell a écrit :

> 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). :-)

For sure... ;)

> 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). 
> 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.

System emulation seems to be an easier goal to reach, I might be wrong. 
In the OpenDarwin CVS tree, there is a qemu version with linux-user 
enabled on Mac OS X. It compiles fine, but in fact most of the syscall 
are just turned off, or stripped down. If you want to test it:
cvs -d :pserver:address@hidden:/Volumes/src/cvs/od 
login
>pass: cvs
cvs -d :pserver:address@hidden:/Volumes/src/cvs/od co 
-P proj/darwine/related/qemu

> 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)?

Endiannes is definitely _the_ issue, at least for me. Since we won't 
just translate simple sycalls, but function call over library, so the 
dll can access the exe Little Endian memory. My idea was to lock LE 
memory zones (using mprotect), and as soon as a Wine ppc DLL try to 
access this block of memory catch the signal raised and do the needed 
swapping. I did test this trick while loading the PE litlle endian EXE, 
and it worked fine. Also about working directly on qemu-fast, I prefer 
doing the job directly in Wine :P But why not using Qemu for its 
initial purpose?

Pierre