On Mar 24, 2004, at 10:18 AM, Morgan Winer wrote:
My question is simply this: why remove the task_{s,g}et_emulation
functionality from the Mach kernel?
While Apple may not need these functions, there are many other
independent developers, myself included, that could make use of task
emulation, perhaps as open-source projects or otherwise.
The main reason was that it added complexity to every trap - at a very low level where such complexity can really add to the cost of a trap (because we may not otherwise have to be in a mode where we could detect the existence of emulations - like having to be in virtual mode on PowerPC processors). There were also extensions to the trap mechanisms that didn't fit into the emulation model and nobody had time to make them fit. Surely, the emulation vector logic could haven been re-written to have a larger machine-dependent component to avoid having the performance implications of the current implementation. You could also add meaningful handling of the additional traps that weren't part of the pre-fast-trap design. But, as there were no known clients of such a facility on the horizon, it got scheduled at the bottom of the pile. I don't think there is any philosophical argument against it getting re-implemented in such a "more efficient" manner. It's just that nobody has signed up to do it. --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.