[coyotos-dev] Coyotos boot

[Jonathan S. Shapiro]

On Tue, 2008-04-08 at 05:18 +0200, Pierre THIERRY wrote:
> Scribit Jonathan S. Shapiro dies 07/04/2008 hora 22:19:
> > If it is desired to implement a persistent system, it is the
> > responsibility of some (unspecified) program in the mkimage to
> > periodically call the snapshot interface and arrange for checkpoint
> > drain. If this is not done, the system is non-persistent.
> 
> I suppose it is also this unspecified program that will tell the kernel
> where to find the persistent objects and where to write checkpoints. Is
> it supposed to be the space bank, in a typical configuration?

Dear God, no! The space bank has enough to do allocating storage!

You are now asking about persistent object load/unload, which is
different from bootstrap. Think of it this way:

When the kernel goes to "prepare" a capability (convert it to in-memory
form), it consults the following items:

  1. The hash table of objects that are already in memory.
  2. The table of object range managers.

The kernel has a built-in object range manager for ROM regions. There is
also a mechanism for a non-persistent process to act as an object
server. The kernel says, in effect, "I need the GPT whose OID is 5 and
whose allocation count is 22". The object server responds either "no
such object exists" or "I have loaded it".

On write-back, a similar protocol operates in reverse. It is slightly
complicated by the addition of commit generations to the protocol.

The kernel has no knowledge of how/where objects are written (if at
all).

> 
> > So to implement a non-persistent system, the current design can be
> > used directly.
> 
> Thanks, I think I see approximately how.


shap