# Boot sequence

One of Dusk OS' defining quality is the fact that it boots from a tiny kernel
and then builds the entirety of the system from source, at boot time. This page
describes the boot process.

## Arch-specific bootloader

When the machine powers up, what it does depends on that machine. Arch-specific
provisions have to be made to ensure that:

1. The binary kernel is loaded in memory.
2. The "bootsrc" contents (see below) is loaded in memory and that the kernel
   knows where to find it.
3. We jump to the kernel's first address in memory.

At this point, we have a the HAL (doc/hal) as well as an interpret loop. After
having done its core initialization, the kernel makes starts its interpret loop
by feeding itself from "bootsrc".

## bootsrc

The "bootsrc" contents comes from /xcomp/boot.fs and is loaded, in its source
form, in memory by the arch-specific bootloader.

Its role it to supply the system with Dusk's "base" set of words, which will be
used to by the next step of the boot sequence, the "glue code".

## Glue code

When we created Dusk's boot media, we didn't only write "bootsrc" to it, we
appended to it what we call the "glue code". Like "bootsrc", this glue code is
written verbatim right next to "bootsrc" and will be picked up by the interpet
loop once it's done compiling "bootsrc".

That code is arch-specific and its role is to "glue" Dusk's base set of words to
"load init.fs from the boot filesystem".

How it does this is open ended, but it almost invariably implies loading
/sys/file.fs, which then allows us to load /init.fs.

For example, the "glue" code for the PC is a concatenation /drv/pc/int13h.fs,
/lib/drivelo.fs, /fs/fatlo.fs and then /xcomp/i386/pc/glue.fs, which puts it
all together, mounting the system fat into the "bootfs" structbind, and then
loading /sys/file.fs from that filesystem, and then, finally, /init.fs, which
brings us to the last boot sequence step.

Another thing the "glue" code must do it to "register" the units it inlined in
it's boot sequence with "floaded," so that they aren't loaded twice through the
"?f<<" word. For example, in the case of the PC platform, if it didn't register
/fs/fatlo.fs, it would end up being loaded twice in memory.

## init.fs

The last step of the boot sequence has a base set of words, I/O, files. It's
pretty well set up. Its role is to get the system to its "final destination",
which depends on the will of the operator.

Most of the time, the final destination is to get to an interactive prompt,
which is most often done through /sys/rdln.

How it does this is very open ended and depends on the machine and the
operator's inclinations. It's also the part of the boot sequence that is the
easiest to change, and is likely to often be adjusted by the operator.
