Keywords: arch

Up: HAFTA Architecture Overview Previous: 2 Checkpoint Library Contents
Subsections

- 3.1 Language
  - 3.1.1 Nebuloids
  - 3.1.2 Procedures
  - 3.1.3 Processes
  - 3.1.4 The System
- 3.2 Compiler
- 3.3 Runtime
- 3.4 Nebuloid Modules

# 3 Overlord

The overlord is the runtime component of the HAFTA package. It is broken into a series of programs, only one of which actually needs to run on the target system.

The overlord system consists of a scripting language and script compiler, a psuedo-code interpreter and main loop, and a series of plug-in modules.

These plugin modules provide complete user flexibility as they provide the software and hardware specific features you need for your system.

## 3.1 Language

The Overlord language is designed to allow the user to define a system--what processes should be running, how to start them, what to do if they fail, etc.-and to tell the Overlord what it needs to do in order to keep this system running smoothly. To this end, it utilizes the concept of processes, procedures (procs), and nebuloids. These concepts are defined in the following sections.

### 3.1.1 Nebuloids

Perhaps the most interesting concept of the Overlord language, nebuloids are a common, simple interface to Overlord plugin modules, and provide most of the power of Overlord language scripts. They can be thought of much like variables-in fact, one of the major nebuloid modules is the VAR module-except with the ability to perform functions when read, such as checking the memory usage of a process. How exactly a nebuloid behaves is based entirely on the module it uses.

Nebuloids can be assigned to and read from, though not every module supports these abilities. Every time a nebuloid is read from, it generally performs whatever function the module was designed to do. Many modules also require that the nebuloid be instantiated, in order to give the module context about what task exactly it is to be performing. For example, when the LOG module is instantiated, it is told where it will be logging to (stderr, a file, or the syslog). When the LOG nebuloid is read from, it takes the message to be logged and the severity of the log message as arguments.

### 3.1.2 Procedures

Procs are simply a collection of Overlord scripting commands which can be called at specific intervals or by other procs, etc.

### 3.1.3 Processes

A process definition in the Overlord language corresponds directly with a process running in a UNIX-like environment. The process definition tells the overlord how to start a process, what to do when it dies, and contains nebuloids and procs to aid in determining whether or not that process is misbehaving.

Processes also have the concept of dependencies, which are simply other processes which must be running in order for that process to function properly. It is ensured that these dependencies are running when the process is started, and the process is notified if one of the other processes it depends on fails. The user can determine the best course of action in this case, whether it be to simply kill off the process and let the Overlord restart it, to simply ignore it and let the process itself deal with it, or to attempt to notify the process in some way that its dependency is temporarily unavailable.

### 3.1.4 The System

A system simply is a collection of processes, procs, and nebuloids instances (collectively known as policy). The procs and nebuloids defined here can be accessed system-wide by scripting commands. (Procs and nebuloids defined in processes can only be accessed within their own process.) The system also has the concept of dependencies; it must be told what processes must be running for the system to function.

## 3.2 Compiler

The script compiler system consists of a compiler, olc, which creates readable assembly language form and an assembler, ola, which converts the assembly into a binary pcode format.

This process can occur on your development platform and only the pcode binary and olrt, the overlord runtime needs to be placed on the target hardware.

A further advantage is the compiler could run on one architecture and the runtime on another. The binary pcode format is architecture independent.

## 3.3 Runtime

The runtime component is responsible for reading the binary pcode, resolving any module dependecies, loading the modules and then monitoring the system to ensure the dependencies are maintained. If a dependency fails, the runtime takes whatever action was defined in the scripts. These actions are usually implemented using modules. For example, if the script called for restarting a program and logging the failure, the EXEC and LOG modules would be used to provide this functionality.

## 3.4 Nebuloid Modules

The purpose of the nebuloid modules is several fold. The modules allow you to only include the features you need, thus keeping the runtime size as small as possible. The modules allow the compiler and interpreter to be written in pure C with no implementation specific features. All the hardware and os specific code is in the modules.

The system can be compiled with either static modules linked into the runtime or with the modules provided as shared objects. This allows for easier field upgrading of modules.

Modules can be as simple as the VAR module which provides the concept of a variable to the scripting language or slightly more complicated with os specific features such as MEM which gives the current memory usage of a particular process or as complicated as you need to talk to your particular hardware.

Up: HAFTA Architecture Overview Previous: 2 Checkpoint Library Contents