No description
  • C++ 97.1%
  • C 1.6%
  • TypeScript 0.4%
  • Rust 0.4%
  • Assembly 0.3%
  • Other 0.2%
Find a file
Glowman554 b1e6d5e3c1
Some checks failed
Automatic Release / build (push) Has been cancelled
first working rust driver
2022-10-16 00:18:16 +02:00
.github/workflows dont waste time building the docs if not needed 2022-08-06 22:43:38 +02:00
core first working rust driver 2022-10-16 00:18:16 +02:00
devices first working rust driver 2022-10-16 00:18:16 +02:00
docs bringing back the docs 2022-08-06 02:03:16 +02:00
features first working rust driver 2022-10-16 00:18:16 +02:00
filesystems Mouse fix & fs changes 2022-05-08 09:34:26 +02:00
foxos_rs first working rust driver 2022-10-16 00:18:16 +02:00
tools/doc fixed functions containing [] in the name 2022-08-10 19:28:44 +02:00
.gitignore first working rust driver 2022-10-16 00:18:16 +02:00
docs.txt added documentation 2022-09-25 01:59:02 +02:00
LICENSE Initial commit 2021-12-06 20:50:45 +01:00
Makefile added simple graphics interface 2022-03-26 20:48:04 +01:00
Makefile.flags almost working higherhalf port 2022-04-16 20:01:59 +02:00
Makefile.module first working rust driver 2022-10-16 00:18:16 +02:00
README.md update readme 2022-09-25 12:03:03 +02:00

Horizon

Horizon is planed to become the main FoxOS kernel at some point. We decided to rewrite the kernel with some stricter design principles and to make it more modular.

The project structure will look something like this:

  • /core -> contains the core kernel stuff like paging and memory management it will also contain some very basic drivers like the VGA/serial and ps2 drivers.
  • /devices/<device name> -> contains the drivers for the device as a loadable module.
  • /filesystems/<fs name> -> contains the drivers for the filesystem as a loadable module.
  • /features/<feature name> -> contains the kernel features as a loadable module.
  • /tools/<tool name> -> tools used to build the kernel / the documentation

The strict design principles

  • every code file needs to be in a location that makes sense (not putting a header file for a list in the net folder)
  • the core kernel contains the vfs/network stack but no actual device drivers the device drivers are in the /<device name> as loadable modules (does not apply for the stivale2 bootmodules vfs driver)
  • the loaded drivers can manually scan for the device in case of for example ata or call a register_pci_driver function to register a function witch gets called when a device is found
  • the modules get loaded as early as possible
  • the vfs is going to be as simple as possible on the kernel side. The vfs is going to implement the following functions:
    • file_t* open(char* path)
    • void close(file_t* file)
    • void read(file_t* file, void* buffer, size_t size, size_t offset)
    • void write(file_t* file, void* buffer, size_t size, size_t offset)
    • void delete(file_t* file) // also closes file
    • void mkdir(char* path)
    • dir_t dir_at(int idx, char* path) // reurn is_none in struct
    • void touch(char* path)
    • void delete_dir(char* path)
  • A module can specify the following function and they fill be called in that order by the kernel:
    • init (directly called after loading)
    • device_init (called in the device init phase of the kernel)
    • fs_init (called after kernel started all known devices should scan disks for the filesystem and then register a vfs node with <fs_name>-<id> (the id is just a internal number in the driver counting up)
  • The rules described here still apply.
  • Syscall's are implemented by id's. there will be always id 0 (get_syscall_id) witch returns the id for a syscall searched by name