Bananymous
9eb3834ae5
If the processor has invariant TSC it can be used to measure time. We keep track of the last nanosecond and TSC values and offset them based on the current TSC. This allows getting current time in userspace. The implementation maps a single RO page to every processes' address space. The page contains the TSC info which gets updated every 100 ms. If the processor does not have invariant TSC, this page will not indicate the capability for TSC based timing. There was the problem about how does a processor know which cpu it is running without doing syscall. TSC counters may or may not be synchronized between cores, so we need a separate TSC info for each processor. I ended up adding sequence of bytes 0..255 at the start of the shared page. When a scheduler gets a new thread, it updates the threads gs/fs segment to point to the byte corresponding to the current cpu. This TSC based timing is also used in kernel. With 64 bit HPET this probably does not bring much of a benefit, but on PIT or 32 bit HPET this removes the need to aquire a spinlock to get the current time. This change does force the userspace to not use gs/fs themselves and they are both now reserved. Other one is used for TLS (this can be technically used if user does not call libc code) and the other for the current processor index (cannot be used as kernel unconditionally resets it after each load balance). I was looking at how many times timer's current time was polled (userspace and kernel combined). When idling in window manager, it was around 8k times/s. When running doom it peaked at over 1 million times per second when loading and settled at ~30k times/s. |
||
|---|---|---|
| .vscode | ||
| BAN | ||
| assets | ||
| bootloader | ||
| kernel | ||
| ports | ||
| script | ||
| toolchain | ||
| userspace | ||
| .clangd | ||
| .gitignore | ||
| .gitmodules | ||
| .pre-commit-config.yaml | ||
| CMakeLists.txt | ||
| LICENSE | ||
| README.md | ||
| base-sysroot.tar.gz | ||
| bos | ||
README.md
banan-os
This is my hobby operating system written in C++. Currently supports x86_64 and i686 architectures.
You can find a live demo here
If you want to try out DOOM, you should first enter the GUI environment using the start-gui command. Then you can run doom in the GUI terminal.
Features
General
- Ring3 userspace
- SMP (multiprocessing)
- Linear framebuffer (VESA and GOP)
- Network stack
- ELF executable loading
- AML interpreter (partial)
- Basic graphical environment
- Terminal emulator
- Status bar
- Program launcher
- Some nice apps
- ELF dynamic linking
- copy-on-write memory
- file mappings
- anonymous mappings
Drivers
- NVMe disks
- ATA (IDE, SATA) disks
- E1000 and E1000E NICs
- RTL8111/8168/8211/8411 NICs
- PS2 keyboard (all scancode sets)
- PS2 mouse
- USB
- xHCI
- EHCI
- OHCI
- UHCI
- Keyboard
- Mouse
- Mass storage
- Hubs
- ...
- virtio devices (network, storage)
Network
- ARP
- ICMP
- IPv4
- UDP
- TCP (partial and buggy)
- Unix domain sockets
- SSL
Filesystems
- Virtual filesystem
- Ext2
- FAT12/16/32
- Dev
- Ram
- Proc
- Sys
- 9P
Bootloader support
- GRUB
- Custom BIOS bootloader
- Custom UEFI bootloader
Code structure
Each major component and library has its own subdirectory (kernel, userspace, libc, ...). Each directory contains directory include, which has all of the header files of the component. Every header is included by its absolute path.
Building
Needed packages
apt (tested on ubuntu 22.04)
# apt install build-essential git ninja-build texinfo bison flex libgmp-dev libmpfr-dev libmpc-dev parted qemu-system-x86 cpu-checker
pacman
# pacman -S --needed base-devel git wget cmake ninja parted qemu-system-x86
Compilation
To build the toolchain for this os. You can run the following command.
NOTE: The following step has to be done only once. This might take a long time since we are compiling binutils and gcc.
./bos toolchain
To build the os itself you can run one of the following commands. You will need root access for disk image creation/modification.
./bos qemu
./bos qemu-nographic
./bos qemu-debug
./bos bochs
You can also build the kernel or disk image without running it:
./bos kernel
./bos image
To build for other architectures set environment variable BANAN_ARCH=arch (e.g. BANAN_ARCH=i686).
To change the bootloader you can set environment variable BANAN_BOOTLOADER; supported values are BANAN (my custom bootloader) and GRUB.
To run with UEFI set environment variable BANAN_UEFI_BOOT=1. You will also have to set OVMF_PATH to the correct OVMF (default /usr/share/ovmf/x64/OVMF.fd).
To build an image with no physical root filesystem, but an initrd set environment variable BANAN_INITRD=1. This can be used when testing on hardware with unsupported USB controller.
If you have corrupted your disk image or want to create new one, you can either manually delete build/banan-os.img and build system will automatically create you a new one or you can run the following command.
./bos image-full
I have also created shell completion script for zsh. You can either copy the file in script/shell-completion/zsh/_bos to /usr/share/zsh/site-functions/ or add the script/shell-completion/zsh to your fpath in .zshrc.
Contributing
As the upstream is hosted on my server https://git.bananymous.com/Bananymous/banan-os, merging contributions is not as trivial as it would be on GitHub. You can still send PRs in GitHub in which case I should be able to download the diff and apply it manually. If you want, I can also provide you an account to my git server. In this case please contact me (email, discord).
As this is mostly a learning experience for me, I would appreciate if you first contacted me about adding new features (email, discord, issue, ...). If you send a PR about something I was planning on doing myself and you didn't ask me, I will probably just close it. Bug fixes are always welcome!
Commit message should be formatted followingly
- First line is of the form "Subject: Description", where Subject tells the area touched (Kernel, Shell, BuildSystem, ...) and Description is brief description of the change done. First line should fit fully in 72 characters.
- Body of the message should further describe the change and reasoning behind the change.
All commits should pass the pre-commit hook defined in .pre-commit-config.yaml. For instructions on how to setup pre-commit, please see https://pre-commit.com/#install.