Prex Technology Overview

Table of Contents

• Prex Components
• Microkernel
• Device Drivers
• System Servers
• Emulation Libraries
• Boot Loader

Prex Components

The following figure illustrates the Prex components.

The Prex microkernel provides only fundamental functions to abstract a processor and minimum hardware. In addition, it provides some real-time support functions for a real-time task. The microkernel also provides standard kernel services for the device drivers. There exists a strict interface for the thin layer called as "Architecture Dependent Layer" in the microkernel.

The other basic OS functions like process, file system, networking etc., are provided by system server tasks. There is no characteristic difference between server tasks and normal tasks. The tasks will communicate with other by using IPC message via a microkernel. Prex will also provide some interface emulation libraries for an application interoperability. Although the server tasks are required to run UNIX processes, a native real-time task can work without any system servers.

Microkernel

• Simple & Small: Move OS functions to user mode as much as possible.
• Easy to Port: Define common interface for various processor architectures.
• POSIX Support: Provide minimum kernel support for POSIX.
• Real-time Capable: Execute native real-time tasks directory on the Prex kernel.

• Object - holds a queue of messages.
• Message - is used to communicate between threads.
• Task - is a container which holds threads, memory maps, and objects.
• Thread - is a minimum execution unit including processor's register state.
• Scheduler - decides which thread can use processor.
• Virtual Memory - provides memory protection, virtual address mapping.
• Timer - manages timer lists for applications & drivers.
• Exception - is a hardware interrupt or event from processor.
• Device - provides common interface to access device drivers.
• Synchronize Object - supports mutexes, condition variables, semaphores.
• System - provides some useful system functions. e.g. statistics, log, time etc.

Device Drivers

Prex device drivers work in kernel mode. All device drivers are stored in one single driver module, and this is separated from the kernel module. The driver module is linked with the kernel at boot time, and all device drivers are initialized at that time.

The interface between the kernel and drivers are defined clearly as "Driver Kernel Interface (DKI)". The kernel provides the following services for device drivers.

• Device object service
• Kernel memory allocation
• Physical page allocation
• Interrupt handling service
• Scheduler service
• Timer service
• Debug service

System Servers

The Prex tasks can communicate with each other by sending message to the specific object, as illustrated below.

Prex provides some standard server tasks to support generic OS functions that are removed from the kernel. The server tasks include:

• Process server
• File system server
• Exec server
• Network server
• Boot server

A server task will create its object named like "fs", "proc", or "exec" in the kernel object name space. Each user mode task will send a message to these objects in order to use the server services.

A server task can re-send the received message to another task. This mechanism can allow servers to "forward" the specific message to another server. For example, the proxy server will forward a received message to the remote proxy server via network.

Emulation Libraries

Prex provides some libraries to emulate POSIX interfaces. They will include standard UNIX system calls, pthread, and real-time extension. The typical works of these libraries are to pack the application's request into a message, and send it to the appropriate server. It will encapsulate the message structure defined by each server task. For example, an application can use fork() system call as a library routine, which will automatically send the message to the process server. So, there is no need to modify the source code of the existing UNIX applications to run it on Prex.

The emulation libraries can be made not only for POSIX but also for API of other OS. This allows Prex to support the execution of various different OS applications without changing the system servers. The developers will benefit from the source level compatibility of existing applications.

Boot Loader

Prex provides the OS boot loader if it is required on the target platform. The boot loader will support the following minimum functions:

• Minimum Setup: Program some essential registers for processor or hardware. e.g. disabling interrupts
• Boot Information: Collect some boot information if it needed. e.g. memory size
• Program Loading: Copy some programs to RAM if it is needed. e.g. kernel, driver, boot tasks etc.

Since the boot mechanism depends on the hardware of each system, its design is not strictly defined.
Note: It's better to use existing boot loader if possible.