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 | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.