Ok, What's the Environment Model like?
Once upon a time there were up to three separate environment models for Grail (Black,
Gray, and White). After a lot of long hard thought upon this, the concept has been
essentially dropped. The amount of complexity it would added to the kernel and all the
support code was, in the final analysis, deemed to be more trouble than it was worth.
What was wanted was to be able to disable paging (and therefore not suffer the potentially
crippling wrath of sequential TLB misses) and secondly prevent your applications
performance to degrade or be choppy because of multitasking.
Why not allow such? If we did go with the ability to do mode switches as such, more
code would be required and thus the kernel would bloat and be less optimized. It was
thought that, in the end, only democoders and a few hacker types would opt for these more
primal modes.
Separate segments are kept for the kernel, fs device object, and debugger at CPL0,
and all the other applications at CPL3.
The normal environment model uses a UNIX-like flat-memory paradigm with paging and
interesting variants of virtual memory management along with both scheduled and preemptive
fair-turn time-sliced multi-tasking.
Besides the normal paged virtual memory strategies, Grail has a curious extension to
this called a Godet, which essentially maps unused address space to specific files
allowing you to address large files as if they were in memory (ie, no damn fiddling with
fopen/fread, etc -- just access it).
This model also boasts management of up to 110 simultaneous tasks (in the current intel
build: properly you should ask the kernel how many it supports directly -- don't assume.
Might go up or down from build to build, cpu to cpu.)
As said, because of the paging U/S protection mechanism (along with standard CALLGATEs)
it is more likely that your applications will survive a hit.
--min/0.00
|
