forked from lolo859/vystem
24 lines
1.7 KiB
Markdown
24 lines
1.7 KiB
Markdown
# Naming scheme
|
|
|
|
Shelter has a very specific way of organizing subsystems.
|
|
First, each part of the kernel (except `main.c` which is responsible for the boot process) is in his own folder. To this date, there is 6 main parts:
|
|
- `cpu`: CPU abstractions
|
|
- `kernel`: kernel services
|
|
- `std`: Shelter standard library
|
|
- `memory`: the whole memory subsystem
|
|
- `irq`: all thing IRQ-related (GDT, TSS, IDT, IRQ handler and GSI)
|
|
- `devs`: all things devices-related, including drivers, Device System API and ACPI parsers
|
|
|
|
Then, each of these parts have specific subsystem or API prefix. These prefixes always start by `sh_` and doesn't include the part each subsystem or API is in. For exemple, the serial outputing API prefix is `sh_serial_`.
|
|
|
|
The `std` part is the only part where, when not precised, the prefix will be shortened to only `sh_`, like `sh_malloc` or `SH_STATUS`.
|
|
|
|
In all the subsystems and API described in this documentation, the prefix will always be indicated.
|
|
|
|
These prefixes extand to names of functions, macros and type/structures. Here is the naming style for each of these entity:
|
|
- functions: all letters should be lowercase, starting with the prefix in lowercase. Example: `sh_serial_send_byte`
|
|
- macros: all letters should be uppercase, starting with the prefix in uppercase. Example: `SH_PAGE_RW`
|
|
- types/structure: the name should start with the prefix in lowercase and continue with the type/structure name in uppercase. Example: `sh_page_PAGE_TABLE_POOL`.
|
|
|
|
Please avoid abreviations/acronyms in the type name, instead define the abreviation/acronym inside the short comment preceding the declaration. Abreviations/acronyms anywhere else is tollerated as long as it's defined somewhere obvious. Don't hesitate to ask if you are not sure.
|