Re: kernel paging (was Hard-limits for kern.maxproc)
Re: kernel paging (was Hard-limits for kern.maxproc)
- Subject: Re: kernel paging (was Hard-limits for kern.maxproc)
- From: Michael Smith <email@hidden>
- Date: Sun, 8 Feb 2009 13:39:03 -0800
On Feb 7, 2009, at 3:34 AM, Steve Checkoway wrote:
Interestingly enough, I'm looking at an older 16-bit embedded system
that takes this approach. By carefully maintaining an overlay call
stack (I don't have a better name for it) and a table of functions
and which overlay they are in, it's possible for one function to
call another function in a different overlay by calling a helper
function that's always mapped into the address space that remaps the
other region. In this case, the code resides in several ROMs and the
mapping can be changed by a single instruction. Obviously it'd be
more complicated to do in a general purpose kernel.
What you're describing is "thunking" (indirect function calls through
a facilitating mechanism).
Thunking code is relatively straightforward because calls are
procedural, and you can make it efficient because code flow is
(realtively) deterministic.
The gotcha with kernel virtual space (pulling this thread back towards
the original topic) is data, not code. Thunking data is hard, because
data access tends to be circumstantial rather than procedural, and
data locality is much less deterministic in a running system. (Yes,
you can use the MMU to make data access seem procedural, but it's
expensive in terms of time, and page granularity makes it wasteful).
= Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden