[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] qemu-darwin-user

From: Jocelyn Mayer
Subject: Re: [Qemu-devel] qemu-darwin-user
Date: Fri, 27 Aug 2004 15:02:27 +0200

On Fri, 2004-08-27 at 14:25, Ian Rogers wrote:
> Hi,
> I think there will be a fundamental limit you reach with this work. The 
> reason being the mach messages can contain pointers to data structures 
> which the kernel fills in. If the pointers are in the wrong endian then 
> the kernel will do something to the application. You can write code to 
> perform transformations on pointers for all the messages you can find 
> documentation on, but some systems will be entirely closed (for example, 
> microsofts messages). Of course you could emulate both the server and 
> the application, but I think you will need a lot of kernel jiggery 
> pokery still. I believe this is the same problem that stops Mac OS X 
> being in a 64bit memory space. You basically need different messages for 
> every kind of pointer you can have. Apple estimated it would take 
> 6months to write support for all those messages, but they revised that 
> up to 2 years iirc. 64 bit OS X applications send 32bit messages 
> currently and pointers to datastructures must appear within the first 
> 4Gb as a consequence. Let me know if I'm wrong.

Seems to me there is no special issue with this point.
If the structure pointed is to be filled by the kernek, then the problem
is exactly the same that what we do for Linux or BSD syscalls.
If the message is to be filled by another application, there is nothing
to do as the memory is in the emulated endianness.
If there is a lot of different structures used by the Darwin kernel, the
way to make things simpler may be to run the IOKIT emulated so all the
structures coming from there would not have to be translated.
Apart from the IOKIT, I don't know which part may be really difficult
(as all user-land parts are to be ran natively / translated by Qemu but
not emulated).

Jocelyn Mayer <address@hidden>
Never organized

reply via email to

[Prev in Thread] Current Thread [Next in Thread]