SalernOS-Kernel
SalernOS-Kernel copied to clipboard
The SalernOS Kernel is a core component of the SalernOS Operating System - A toy OS to learn more about Operating System Development
IMPORTANT
If you're intrested in the development of the SalernOS Kernel, check out the hellow branch. The hellow branch focusses on getting a "Hello world" program to run in userspace. It also aims to speed up Kernel development by including third-party modules (like Limine and limine-terminal-port) and enhance the developer experience with linting, multithreaded Makefiles, and more.
SalernOS Kernel
The SalernOS Kernel is a fundamental component of SalernOS: a toy OS I'm working on.
Source Tree Strucutre
The source tree is structured as follows:
srcContains all the source code for the core parts of the kernelintfContains headers for kernel librariesarchContains architecture-specific code (Not yet) and BootStandard-specific code, like the linker script used to link the kernelkstdContains a pseudo C Standard Library for the kernelklibContains code that is dependent on other parts of the kernel (Such askstd,includeandsrc), but are not important enough to keep inside the core sourcemakeContains files included by the mainMakefileobjIs created by theMakefileand contains the object files (.o) derived from the compilation of the kernelbinIs created by theMakefileand contains the final kernel ELF64 binary
Setup
To set the environment up, just type make setup and hit enter.
Building the Kernel
To compile the entire kernel, just type make kernel and hit enter.
Requirements
- A C Compiler (GCC) for x86_64
- An assembler (NASM) for x86_64
- A linker (LD)
- Make
All required software is bundled with the SalernOS-Buildenv
Source Tree Naming Conventions
- Folders in the main directory must be named using short series of lowercase characters
- Subfolders must be named using
CamelCasenotation and may not exceed 1 word - File names must NOT contain spaces or other special characters, and shall only consist of short series of lowercase characters
These rules do not apply to special files and folders such as Makefiles.
C Source File Structure
- Source Files must contain commented notices, such as licenses, warnings and comments as their first sections.
- Source Files must contain Compiler Directives in order:
- Include statements (From longest to shortest)
- Macros and constants (Horizontaly aligned)
- Source Files can contain optional sections in the following order:
- Type definitions
- Static global variables (Horizontaly aligned)
- Other global variables (Horizontaly aligned)
- Static functions
- Function implementations
Sections must be separated by two blank lines and the file must end with an empty line as well.
Source File Example
// LICENSE
// WARNING
// DESCRIPTION
#include <kerninc.h>
#include "other.h"
static bool aStaticBool;
static uint32_t aStaticUint32;
bool aBool;
uint32_t aUint32;
static void __static_function__() {
return;
}
uint32_t kernel_other_implementation() {
return 50;
}
C Header File Structure
- Header Files must contain commented notices, such as licenses, warnings and comments as their first sections.
- Header Files must contain Compiler Directives in order:
- Include guards
- Include statements (From longest to shortest)
- Macros and constants (Horizontaly aligned)
- Header Files can contain optional sections in the following order:
- Type definitions
externvariables (Part of a table of variables comprised of two columns: type and name - Horizontaly and verticaly aligned)- Function declarations (Part of a table of functions comprised of three columns: return type, name and arguments - Horizontaly and verticaly aligned)
- Header Files must NOT contain:
- Non
externglobal variables - Static functions
- Non
- The body of Header Files must be indented
Header File Example
#ifndef SALERNOS_CORE_KERNEL_HEADERFILE
#define SALERNOS_CORE_KERNEL_HEADERFILE
#include <kerntypes.h>
/*************************
TYPE NAME
**************************/
extern bool anExternBool;
/*********************************************
RET TYPE FUNCTION NAME ARGUMENTS
*********************************************/
void kernel_other_declaration ();
#endif
The variables and functions tables must be organized as follows:
- The top border must start with
/and end with*in the precise column where the bottom border ends - The bottom border must start with
*and end with/. If the header exceeds the longest element's length (Like in the function table example), the/must be one column to the right of the header. Otherwise, the/must be on the same column as the semicolon of the longest element
Assembly File Structure
A structure for .asm files will soon be defined. In the meanwhile, try to match the style of existing files.
Naming Conventions (For src/)
- Type names must follow the POSIX Standard type notation (
name_t) and should be as short as possible - Function names must follow the scheme
kernel_category_target_action, such askernel_kdd_pxcolor_setandkernel_kdd_pxcolor_get. If the category is the target, such askernel_mmap_initialize, thetargetsection can be dropped - Static function names must follow the scheme
__action_target__, such as__get_pxptr__ - Static global variables and global variables must use
pascalCasenotation - Static local variables and local variables must be comprised of lowecase characters and must start with a
_as in_local_variable - Function arguments must be comprised of lowercase characters and must start with
__as in__function_argument - Struct fields must use
CamelCasenotation and must start with_ - Constants and macros defined using
#definemust be comprised of UPPERCASE characters, with words separated by_such as inARGRET(__arg, __val)orPIC1_COMMAND - Constants declared with
constmust be comprised of UPPERCASE characters, with words separated by_and must start with_, such as in_KERNEL_START
Best Practices
- Use 4-space indentation
- Put brackets on the same line as the declaration
- Put
*next to the type in pointer declarations (int* pnotint *p) - Avoid
ifstatements whenever possible - Try to use case-specific types (Such as
uint16_t) instead of generic types likeint - Try to leave blank lines inside scopes to separate code areas
- Try to be as precise as possible with padding and spaces. Any request containing
(){ora=binstead of() {anda = bWILL BE REJECTED WITHOUT FURTHER INSPECTION
Branches
The master branch is used for the current INDEV version. A support branch will be created for every Kernel release (kernel-florence-support for example).
Roadmap
You can find the roadmap here