On 25 February 2010 02:58, Jonathan S. Shapiro <[email protected]> wrote: > 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.
I don't think I would want to eliminate persistence. It's the most interesting feature which differentiates CapROS from other experimental systems and which should make dealing with the system much easier from user's or administrator's point of view. The demarcation line design is simple and it was successfully implemented already but it was somewhat surprising for me. Given that the system can run on SMP there are necessarily relativistic time effects, no single time line. The demarcation event can be inserted into multiple timelines by means of synchronization but a different design may exploit that all communication between processes goes through the kernel and thus the kernel must know if the changed state of one process might possibly be known to other process and build the snapshots somewhat loosely based on IPC invocation. This might be more scalable and waste less time on additional synchronization but it is harder to get right. Also there is communication that does not go though the kernel which has to be taken in to account - shared memory. Thanks Michal ------------------------------------------------------------------------------ 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
