Unlike many distributed systems, the kaneton microkernel based distributed operating system use specific and specialised capabilites rather than generic capabilities to increase scalability.
Consider a modern file system with billions of inodes; this file system certainly wants to build capabilities with a 64-bit identifier.
Consider now another service, for example a printer service, listing every printer of the system. This service certainly wants to use 16-bit identifier in its capabilities because there will certainly never be more than 65000 printers on this system.
Each server is different so each server needs its own capability format.
The use of specific and specialised capabilites forces the programs to ask the servers to generate new capabilites, unlike other systems. Indeed, the other systems generally use generic capabilites to permit programs to generate capabilities by themselves. This was not the kaneton designers' choice and the result is more scalable capabilites but a performance loss in capability generation.
Note that libraries for each capability type manipulation could also have been provided but this was not the kaneton designers' choice either.
Moreover, using this scheme permits servers to use the cryptographic algorithm they want.
Note that the capability generation does not often happen so the performance loss is not dramatic. Moreover, a capability can be generated and used by many other tasks because capabilites are generally used to restrict permissions. A capability is not unique to its user, so a program can generate a capability and distribute it to many other programs giving them the same permissions.
To conclude, this system is performant in a normal use but can become slow if a program has to generate many different capabilities, this case being seldom.
The use of specific capabilities also allows servers to create capabilities, for example, without identifier or with extra permission fields or with maximum security using for example a 128-bit check field.
Note that the use of the check field does not guarantee security on a distributed system. For this reason, the kaneton microkernel based distributed operating system can evolve with three security policies:
- No security: with this policy, the security field of the capabilities is not used. No cryptography is used on the system to guarantee security.
- Local security: with it, the capabilities are protected from malicious programs and users using the check field. So, while there is no network message passing of capabilites, the system can be considered as safe.
- Global security: with this security policy, the distributed operating system is safe. Every capability is protected with its check field but in addition each message on the network is protected by cryptographic algorithms.
The kaneton microkernel internally uses a set manager which organises data for other kernel managers. The entire microkernel is based on the sets.
Using this manager leads to a very elegant and maintenable source code. From this fact, every kernel manager uses the set manager to store its data. For example the task manager uses the set manager to store every task of the system. Additionnaly, each task contains a set composed of the threads of this task etc..
Such a system provides an easy way to store data without effort. The task manager for example does not care about how to store data.
Moreover, it is possible to optimise the code where it is needed. In this case, it will be useful to optimise the data structures in the set manager and not in every manager using such a data structure like other systems do.
Indeed, the other operating systems generally use pointers to link kernel structures together and implicitly form sets. Such a source code is human unreadable and leads to many programming confusions and errors.
kaneton being a pedagogical microkernel project, we wanted to use the simplest design possible.
The set manager provides many different data structures like linked-list, double linked-list, circular queue, stack, pipe, array, binary tree, b+-tree etc.. In addition, the set manager can be extended without affecting the other managers using it.
By this way, every kernel manager is now able to use the set manager to store its data. The set manager also provides tools like iterators to easily and quickly go through sets.
The set manager interface is generic independently of the underlying set implementation. From this fact, a manager using a set can easily modify the set implementation used just by modifying a word in the set reservation line, the other set manager functions calls do not need to be modified.
The set manager is a key concept of kaneton because the whole kaneton core source code is using it leading to a very coherent and beautiful source code.