-
Notifications
You must be signed in to change notification settings - Fork 3
Home
The silcos kernel aims to build a platform for running highly modular and secure systems. Its design allows extensions and modules to be configured in a highly secure and controlled manner, going to the extent of building a in-kernel JIT-framework (in the future). It was and is designed for being compatible with the linux kernel from the user-space, and therefore, compatible with most linux-based applications. It’s main goal is to provide a robust and stable platform for building a operating system, and also giving a common application-framework for all OS software built on top it, therefore, a OS-independent software environment.
This documentation is for developers who have slight knowledge of system programming and the IA32/64 architectures. For in-depth explanation of these techniques refer to the OSDev Wiki because here we focus on what makes the kernel unique.
The kernel source is highly organized and divides the kernel code with respect to modules. Each module is compiled and loaded separately at boot time and holds its own responsibility. All builtin modules are dependent on each other and reference external symbols, by using header files in the common Interface/ folder.
Each KernelModule folder contains four subfolders - Source, Compile, Build, and Wiki and a Makefile.
i) Source - The source folder contains the source code of the module. The source code could further be divided into folder based upon the level of complexity and division of work in the module. Every source file is compiled as a separate unit with GCC.
ii) Compile - The compile folder contains the object files corresponding to each source file in the same directory structure as the source folder.
iii) Build - The build folder contains the *.so file after linking all object files.
iv) Wiki - This folder contains various Markdown files for documenting the kernel source externally.
The kernel is composed of various modules which unify to provide executive services. The following modules are (built-in) required for a complete in-kernel environment -
KernelHost - The KernelHost is responsible for booting the kernel environment and then initializing basic services and all other kernel-modules present at boot-time through the multiboot-protocol. It provides memory-management facilities, basic architecture-support, module loading & symbol support as the most important features. Unlike other modules, the KernelHost is built as a PIE file rather than a shared-library.
HAL - This module is responsible for abstracting away the underlying architectural differences between different hardware platforms and provides other modules with hardware-level services without compromising their platform-independent nature. This services include, but are not restricted to, processor & hardware topology support, ACPI table-parser, symmetric multi-processing support, interrupt & interrupt-controller drivers (.i.e. local and I/O APIC drivers), etc.
ModuleFramework - Supplementing the KernelHost, this module provides various utilities used in programming like data-structures, String, extended debugging support, socket-like connections b/w modules, hashing & encrypting functions, etc.
ObjectManager - Provides the generic object-handle infrastructure required to maintain all the information present in the system in the form of a hierarchy of objects and export them to user-space application through kernel-calls. It provides object-level communication, object searching & parsing, per-process object management, etc.
ResourceManager - This module is responsible for resource-tracking and allocation techniques like demand-paging, PFRA, page-level management, memory-caches, allocators above KPage & Slab, etc. It also manages the lifecycle of processes and gives various forms of IPC.
ExecutionManager - Being responsible for core performance and responsiveness of the system, this module controls the scheduler, tasks, threads, timers, interrupt-handlers, and kernel-calls.
1. The kernel relies on the multiboot specification for getting into its environmental state. For more information, http://download-mirror.savannah.gnu.org/releases/grub/phcoder/multiboot.pdf is link for its documentation.
2. The kernel uses the ELF ABI for loading & linking its modules. Other binary formats are strictly prohibited for specific reasons.
C++, C (for Initor module) and AT&T assembly (along with exceptional NASM) is used for creating kernel code. To learn how to build the kernel, check the Build wiki.