[coyotos-dev] Coyotos boot
Jonathan S. Shapiro
shap at eros-os.com
Mon Apr 7 22:19:20 EDT 2008
On Tue, 2008-04-01 at 01:20 +0200, Pierre THIERRY wrote:
> Is there a detailed description of how Coyotos boots? I don't remember
> seing one, and I'm curious. I'm curious, BTW, because I was wondering
> how a non persistent OS could be ported to the Coyotos kernel.
I am not sure that what follows will answer the question that you are
really asking. The persistence portion of the Coyotos design has been
lagging, because we are currently focused on non-persistent embedded
targets. My guess is that the information you actually want is a cross
between what follows and the persistence design that Charlie Landau is
working on for EROS.
First, a bootable coyotos system consists of two parts:
- The kernel.
- An initial boot image (usually referred to in the notes as a
The mkimage file contains all of the initially loaded objects.
Generically, the boot process assumes that either (1) the mkimage has
been link-edited into the kernel binary image, or (2) the mkimage has
been loaded separately by a multiboot-compliant boot loader
[deprecated]. In either case, the mkimage has been loaded into RAM when
the kernel starts.
On startup, the kernel performs an initial partition of memory into
objects, being careful not to step on the mkimage. Once the object space
is established and initialized, objects are copied from the mkimage into
the in-memory object cache. Any process that is copied is inspected to
determine whether it is currently marked "running". If so, it is added
to the run list as the copy proceeds.
All objects in the initial mkimage are pinned in memory until/unless
they are explicitly destroyed.
There are currently two supported strategies for loading the mkimage:
1. Kernel + module. This is the old version, developed for use with
GRUB. It is slowly going away.
2. Single binary with embedded mkimage. This is now the preferred boot
mechanism, because it works on all platforms and it is compatible
Typically, the mkimage will contain a space bank that allocates
non-pageable objects. There is a kernel interface by which this
spacebank can learn how many pages/GPTs/processes are available in the
initial system configuration.
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.
So to implement a non-persistent system, the current design can be used
I do not know how well this answers your real question. Hopefully it
will turn out to be a useful starting point, and I can provide better
response by iterating.
More information about the coyotos-dev