On Wed, Feb 24, 2010 at 10:45 AM, Charles Landau <[email protected]>wrote:
> KeyKOS, EROS, and CapROS page to persistent storage...
> Non-persistent versions of EROS and CapROS have been envisioned...
Coyotos pages to persistent store, but the implementation of the store is in
user mode and was indefinitely deferred. We have a distinguished
pinned-memory page region from which drivers run, and an entire embedded
system can run from that as well. Our early apps were all deeply embedded
and diskless, so implementing orthogonal persistence wasn't a priority.
I continue to have reservations about orthogonal persistence, and I don't
think that I would put it into an architecture if I were starting today. You
can't eliminate the presence of a semantic boundary at the point where the
persistence demarcation line is drawn, and this has unfortunate implications
for distribution semantics. OTOH, persistence makes scheduler activations
quite hard, and I'm increasingly convinced that a deeply *asynchrous* comm
design would be the right way to go in the future. The OKL4 folks seem to
have ended up with that conclusion as well.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
CapROS-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/capros-devel
