Knowbot Operating Environment Quick Start

Introduction

Here are the basics for starting the Knowbot Operating Environment (KOE) on your system. This document assumes you have already installed the system. (See the KOE installation manual.)

The KOE has a few major components you need to know about:

The namespace

KOE components are connected by a shared namespace. A worldroot server manages the top of the namespace. It must be running before you can use the KOE (the koeboot program described below takes care of this).

Knowbot Service Stations (KSSs).

Service stations run Knowbot Programs. The service station runs a Knowbot Operating System kernel that is layered on top of the standard operating system.

Plugins.

Plugins extend the basic services provided by a KSS. Plugins are trusted code and operate without the security restrictions of KPs.

Three scripts will start and stop the KOE and let you launch Knowbot Programs:

• koeboot, to start a new KOE or ensure that one is running
• submit, to launch KPs, and
• koehalt, to stop a KOE

Although not necessary for starting the KOE, the visualizer is a useful tool for monitoring it. The visualizer shows all the service stations, KPs, and plugins currently running. Another useful tool is nslist, which produces a listing of the namespace. See KOE tools for documentation of other tools.

KOE Boot Program

The koeboot script starts the KOE components necessary to run KPs on your system:

% koeboot

This script starts a KOE described by the koeboot configuration files. The script does two things:

1. A worldroot is started, unless one is already running on the current host.
2. KSSs configured for the host are started. The default configuration consists of only one KSS, with the same name as the host computer.

When a KSS is run, it starts any plugins that have been configured to run. By default, no plugins are started.

The KP Submit Program

To run a Knowbot Program at a service station, you must launch it with the submit program. The $KOSROOT/examples and $KOSROOT/testcases directories contain some sample KPs. The kpshell KP implements an interactive Python mainloop so that you can experiment with commands by typing them in and immediately seeing the results.

By default, the submit program will treat its argument as a file containing a complete KP and launch it to the default KSS (the one with the same name as the current host).

% submit $KOSROOT/testcases/list-namespace.py

The submit program accepts several optional arguments. Three of the most useful are:

• -k [kssname]. Submit KPs the the KSS named kssname.
• -v. Verbose mode. Reports on the KP's status as it is submitted and migrates.
• -1. Treat the arguments to submit as multiple files comprising a single, multi-module KP. The first file should contain the KP class definition.

The submit program connects the KP's standard input, output, and error streams to the terminal, so you can interact with it while it runs.

Internally, the submit program performs the following actions:

1. It locates the destination KSS and submits the KP to it.
2. It acts as a reporting station, receiving status reports when the KP migrates, clones, or terminates, and an I/O server, conveying the KP's standard input, output, and error streams to the controlling terminal.
3. It waits for status and I/O messages from the KP, until it is notified that the KP and all its clones have terminated.

The KOE Halt Program

koehalt terminates the service station(s) started by koeboot. (More precisely, if koehalt is given no arguments it will stop the KSSs that would have been started if koeboot had been invoked with no arguments.)

% koehalt

koehalt does not, by default, terminate the worldroot or visualizer. As a result, worldroot servers are left to run on a host over the course of multiple sessions. (koehalt -a will halt the worldroot and visualizer in addition to KSSs. See the koeboot/koehalt documentation.)