Re: Mac-on-Linux and VM internals
Re: Mac-on-Linux and VM internals
- Subject: Re: Mac-on-Linux and VM internals
- From: Jim Magee <email@hidden>
- Date: Tue, 9 Mar 2004 10:11:41 -0500
On Mar 7, 2004, at 10:34 AM, Samuel Rydh wrote:
>
In order to maximize speed, MOL works at a very low level. Basically
>
MOL hooks all exception vectors (in an OS independent manner) and takes
>
complete control over the MMU. The main benefit is speed (the MMU
>
virtualization
>
costs almost nothing).
>
>
... [snip] ...
>
Also... the documentation explicitly states that vm_map_xxx can't be
>
used safely
>
from a KEXT. Why is that? I believe I don't have to use those
>
functions but
>
it would be interesting to know exactly why there is a difference
>
between
>
a KEXT and the kernel proper.
Hmmm. In the first paragraph you state that you are doing probably the
most unsupported thing possible. And you are worried about using a
handful of not-guaranteed-to-be-supported-long-term SPIs in the second?
Interesting. ;-)
Note that we went out of our way NOT to take your/MOL's approach in
supporting other virtual machines in Darwin/Mac OS X. And we did it for
the reason I just mentioned: it results in a pretty unsupportable
situation long-term (especially if binary compatibility of the KEXTs
doing this sort of thing is required).
But in case your last question is serious: The difference is that when
we release a new kernel update, we release the whole thing. If we make
a change to the vm_map_xxx() implementations that require a change in
the call sites, we can make those in the same binary. If there are
[binary] KEXTs out there that use the same interface, we don't have
that luxury anymore. So, we declare such interfaces "unsafe" (meaning
we provide no release-to-release binary compatibility guarantees for
any KEXT making such calls). You can still use them if you must. But
your KEXT will have to link against a very specific version of the
kernel's KEXT versions - and the KEXT system will refuse to load your
KEXT when the next version of the base kernel comes out.
In the past, we have been lax about "upping" the binary compatibility
version number for the base system. That's because we hoped developers
only used the interfaces we recommended, rather than all the interfaces
available, and we didn't want to refuse to load KEXTs that "played
nice." But we are well on the way to defining a set of Kernel
Programming Interfaces (KPIs) and their associated linkage KEXTs.
These linkage KEXTs greatly restrict the set of available interfaces,
but they greatly increase the stability of the compatibility versions.
All the KEXTs that "play nice" will link against those KPI KEXTs
instead of the kernel as a whole. Once this transition is well
underway, we will not be so reluctant to up the compatibility version
number for the base system. The result: A system that should be much
more stable/reliable for all our users. But KEXTs that have to do
"interesting things" may have to be released more often to better match
the base system.
--Jim
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.