Complete example — flash filesystem

Let's now examine a complete buildfile that starts up the flash filesystem:

[virtual=x86,bios +compress] .bootstrap = {
    PATH=/proc/boot:/bin procnto

[+script] .script = {
    devc-con -e -n5 &
    reopen /dev/con1
    devf-i365sl -r -b3 -m2 -u2 -t4 &
    waitfor /fs0p0
    [+session] TERM=qansi PATH=/proc/boot:/bin esh &

[type=link] /tmp=/dev/shmem
[type=link] /bin=/fs0p0/bin
[type=link] /etc=/fs0p0/etc
[type=link] /usr/lib/



The buildfile's .bootstrap specifies the usual startup-bios and procnto (the startup program and the kernel). Notice how we set the PATH environment variable to point not only to /proc/boot, but also to /bin — the /bin directory is a link (created with the [type=link]) to the flash filesystem's /fs0p0/bin path.

In the .script file, we started up the console driver with five consoles, reopened standard input, output, and error for /dev/con1, and started the flash filesystem driver devf-i365sl. Let's look at the command-line options we gave it:

Enable fault recovery for dirty extents, dangling extents, and partial reclaims.
Enable background reclaim at priority 3.
Specify the highest update level (2) to update files and directories.
Specify the highest number of threads. Extra threads will increase performance when background reclaim is enabled (with the -b option) and when multiple chips and/or spare blocks are available.

The devf-i365sl will automatically mount the flash partition as /fs0p0. Notice the process manager symbolic links we created at the bottom of the buildfile:

[type=link] /bin=/fs0p0/bin
[type=link] /etc=/fs0p0/etc

These give us /bin and /etc from the flash filesystem.