A program is the lowest privileged task on the system. The common user programs are the well-known UNIX programs like
/usr/bin/cc etc. A program is a task with no privilege. All it can do is compute some things, manage data and send messages to more privileged processes.
A service is a server which provides a so-called service. A service waits for messages, performs a task, and returns the result of the service replying the caller.
A driver is a service which can communicate with hardware devices. So, the I/O operations are reserved to tasks which are at least a driver.
Finally, a core is a kind of super-driver in which it provides many services and communicates with hardware devices. Moreover, it is the only task able to modify every system's internal data structure.
In typical microkernel, every task can only be called by less or equal privileged tasks. In kaneton, we decided to break this rule because we found it too restrictive. In fact the core processes are allowed to send asynchronous messages. Without this exception, the microkernel is not able to forward messages, so hardware and software communications are not possible.
The kaneton microkernel does not have processes in the UNIX terms. Indeed, the kaneton microkernel manages tasks. A task is a non-active entity because a task is never scheduled. A task, in the kaneton terms, is an abstraction which describes an execution environment, a context. Each task has an address space describing its useable memory and one or more threads. A task with only an address space and one thread is essentially identical to a UNIX process. The term process is sometimes used in the kaneton documentation to describe a kaneton task.
The thread is the active entity because it is this one which is scheduled. Such a thread belongs to a single task, has a set of registers, a program counter and finally a stack. Needless to say that the kaneton microkernel handles threads as kernel threads.
Each task has three important properties: a class, a behaviour and a priority.
The class is chosen at the task creation time. This property informs the kernel about the nature of the task, its role on the system. In addition, this class will implicitly determine the rights of the task on the system. The different classes are core, driver, service, program. On many architectures, the core, driver and service classes will have the same hardware system priority. Nevertheless, few architectures provide different hardware system privileges like the Intel 32-bit Architecture.
The behaviour specifies the kernel the type of the task from the scheduler point of view. The different values for the behaviour are core, realtime, interactive, timesharing and backgroud. Each behaviour defines a range of priorities for the task.
The priority is a value included in the range defined by the task behaviour. Any thread of a task can update the priority of its task in this range modifying the task priority from the scheduler point of view.
With these properties, a user can create a task very reactive setting an appropriate behaviour and then update its priority to adjust its quantum. This mechanism gives the programs many possibilities and permits them to choose their execution context.
The threads also have an important property: a priority.
Each thread of a task can set its own priority in the range [10, 250[. From this fact, a thread can set itself an higher priority than the other threads of its task. The resulting effect is a thread having a longer quantum so better interactivity. Once again, this mechanism gives more liberty to the programs.
The kaneton microkernel includes a statistics manager which performs runtime statistics on managers.
Indeed, this manager collects information on functions used by each manager including the number of calls, the number of errors and the time passed in each function.
Whenever a function is called and returns, the statistics manager is notified and then updates its data structures.
Through this statistics manager kaneton developers are able to optimise the critical managers and functions.
Needless to say that the set manager is part of the critical managers since the whole kaneton core is based on it.