On Mar 9, 2004, at 9:19 PM, Samuel Rydh wrote:
On Tue, Mar 09, 2004 at 12:40:57PM -0500, Jim Magee wrote:
What if we decide, later on, to change the exception handlers we
have installed (maybe to more optimized versions for the platform)?
You mean, on the fly after the system has booted? Sound like a worse
hack
than what MOL does without the (good) excuse that MOL can't easily make
modifications to the kernel proper...
I must disagree. We have one kernel. It must boot on as many CPUs as possible (currently all CPUs we support). So, the initial exception vector implementations are somewhat generic (and support the worst-case). Once we detect exactly what system we are on (presence of multiple CPUs or not, etc...) we may want to change these vector settings to go directly to optimized versions for that platform (as checking a set of "never changing state flags" in each exception handler invocation can be considered wasteful). The platform KEXTs are the only ones that know this information for sure - and we have to be running for a while to run them. So, there you go. A legitimate (although currently hypothetical) reason we would need/want to do this. Because the platform KEXTs are just KEXTs (like yours), and there is no explicit dependency between them, it would be a race to see who got their changes in last (and I imagine the platform KEXT wouldn't write the vectors itself, but instead inform the base kernel of the presence [or absence] of key features, and we would would update the vectors ourselves to one of a set of handlers we already have defined in the base kernel).
Your original statement about needing to wire down all of MOL to keep
the
system running seems somewhat telling in this regard.
No no... not the all of MOL. Just the virtualized RAM. The RAM has to
be
wired down (currently) because the MOL module has no way of knowing
that a particular page is about to be swapped out (or whatever). If the
kernel module could be told (through some suitable mechanism) about
this
event, then it would be trivial to flush any references to that page.
That is, MOL is designed to function as a software TLB cache with
respect
to the operating system when pageable memory is used for RAM.
Sure, there are such suitable mechanisms in our kernel. They're just at a much higher level than you want. This all stems from divergent design philosophies. Our kernel believes in providing "abstracted hardware" services to code that implements other operating systems. Meanwhile MOL prefers to provide non-abstracted pure virtual emulations of the hardware to other OSes. While one can envision a layering of these two software systems, it normally wouldn't be to have the abstraction-providing one sitting underneath the pure-virtual one. But that's the situation we find ourselves in - with the virtualizing software trying to pry the abstraction-providing software away from the true hardware (with the abstraction-providing software trying not to give up control). --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.
participants (1)
-
Jim Magee