On Tuesday 04 January 2005 19:44, address@hidden wrote:
I became interested in QEMU when a Darwin port was revealed.
Unfortunately, user mode emulation isn't supported yet. However, even
when
it is, I don't think (as I understand it) it will allow non-native
binaries
(in either ELF or Mach-O format) to call native ones. I found it
interesting the documentation touts that user mode emulation can run
WINE,
but the entire WINE set of libs would have to run under emulation.
I understand that there is an inherent difficulty in that x86
executables
assume they are running in little endian mode (I call it mode since
some
CPUs can run in either), but if one wants to have a shared user space
with
one set of natively optimized libraries what better way to implement
it? We
would have faster linking and faster CPU emulation.
The problem is that to mix any two different types of code (big/little
endian, native ppc vs emultated x86, whatever) you need a well defined
interface between the two so that you can insert thunks. These thunks
do whatever conversion is necessary. To do this you need to know all
information passed across the interface. In practice this means not
just the actual function arguments, but also any data passed/returned
indirectly via pointers, and any data accessed via global variables.
For userspace emulation the thunked interface is the linux syscall
layer. This is designed to be a clean interface between two different
types of code, so translating from guest syscalls to host syscalls is
relatively simple.
However shared libraries tend to have much less cleanly defined
interfaces. They tend do share data structures, and be much more
closely linked. This makes adding the translation layer between the
two much more difficult, if not impossible. It generally requires
designing the interface with this in mind from the start, and in
general can't be retrofitted to existing libraries. Shared libraries
(aka dlls) share an address space with the main application, so tend
to be very hard to disentangle from each other.
Paul
_______________________________________________
Qemu-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/qemu-devel