From: Jocelyn Mayer <l_indien@magic.fr>
To: Ian Rogers <irogers@cs.man.ac.uk>
Cc: Darwine List <darwine-devel@lists.sourceforge.net>,
qemu mailing list <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu-darwin-user
Date: Fri, 27 Aug 2004 15:02:27 +0200 [thread overview]
Message-ID: <1093611747.12220.128.camel@jma1.dev.netgem.com> (raw)
In-Reply-To: <412F2841.4090407@cs.man.ac.uk>
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 <l_indien@magic.fr>
Never organized
next prev parent reply other threads:[~2004-08-27 13:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-27 11:13 [Qemu-devel] qemu-darwin-user Pierre d'Herbemont
2004-08-27 12:08 ` Jocelyn Mayer
2004-08-27 12:17 ` Jocelyn Mayer
2004-08-27 12:19 ` Pierre d'Herbemont
2004-08-27 12:25 ` Ian Rogers
2004-08-27 13:02 ` Jocelyn Mayer [this message]
2004-08-27 13:49 ` Ian Rogers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1093611747.12220.128.camel@jma1.dev.netgem.com \
--to=l_indien@magic.fr \
--cc=darwine-devel@lists.sourceforge.net \
--cc=irogers@cs.man.ac.uk \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).