Tilck
A Tiny Linux-Compatible Kernel
Install / Use
/learn @vvaltchev/TilckREADME
What \ Arch | i386 | riscv64 | x86_64 (build)
--------------------|----------------------|--------------|------------------
Tests | |
|
Toolchain debian |
|
| N/A
Toolchain fedora |
|
| N/A
Toolchain archlinux |
|
| N/A
Contents
Overview
<p align="center"> <img src="http://vvaltchev.github.io/tilck_imgs/v2/overview.png" border="0"> </p>What is Tilck?
Tilck is an educational monolithic kernel designed to be Linux-compatible at
binary level. It runs on i686 and RISCV64 at the moment. Project's small-scale
and simple design makes it the perfect playground for playing in kernel mode
while retaining the ability to compare how the very same usermode bits run on
the Linux kernel as well. That's a rare feature in the realm of educational
kernels. Because of that, building a program for Tilck requires just a gcc-musl
toolchain from bootlin.com. Tilck has no need
to have its own set of custom written applications, like most educational kernels do.
It just runs mainstream Linux programs like the BusyBox suite. While the
Linux-compatibility and the monolithic design might seem a limitation from the OS
research point of view, on the other side, such design bring the whole project much
closer to real-world applications in the future, compared to the case where some
serious (or huge) effort is required to port pre-existing software on it. Also, nothing
stops Tilck from implementing custom non-Linux syscalls that aware apps might take
advantage of.
Future plans
In the long term, Tilck might become widespread for embedded systems on
which a fully deterministic and ultra low-latency system is required.
With a fair amount of luck, Tilck might be able to fill the gap between
Embedded Linux and typical real-time operating systems like FreeRTOS or
Zephyr. The kernel already runs on RISCV64 and at some point it will be ported
to the ARM family. It might be adapted to run on MMU-less CPUs as well. Tilck
would be a perfect fit for such use cases because consuming a tiny amount of RAM
has always been a key point in Tilck's design. Indeed, the kernel can boot and
run on a QEMU machine with just 3 MB of memory today.
In addition to that, adding a basic support for networking and storage is part of the plans even if details have not been defined yet. Networking support might be limited to UDP + IP (at least at the beginning) and usable on a limited set of network cards. The same applies for storage: not all kinds of block devices will be supported, and a few filesystems (maybe just fat32 and ext2) will implemented in the kernel. The support for FUSE filesystems will be considered.
One major milestone for the project will be to support both networking and storage for a specific SoC like Raspberry Pi 3 (or 4) but that could possibly happen only after Tilck has been ported to ARM64.
What Tilck is NOT ?
-
An attempt to re-write and/or replace the Linux kernel. Tilck is a completely different kernel that has a partial compatibility with Linux just in order to take advantage of its programs and toolchains. Also, that helps a lot to validate its correctness: if a program works correctly on Linux, it must work the same way on Tilck as well (minus not-implemented features). But, having a fair amount of Linux programs working on it, is just a starting point: with time, Tilck will evolve in a different way and it will have its own unique set of features as well.
-
A kernel suitable for a desktop operating system. No X server works on Tilck, not only because a considerable amount of extra features will be required for that, but because working in that direction is completely outside of project's goals. See also: https://github.com/vvaltchev/tilck/discussions/81
Tilck vs Linux
Tilck is fundamentally different from Linux as it does not aim to target multi-user server nor desktop machines, at all because that would be pointless: Linux is not big & complex because of a poor implementation, but because of the incredible amount of features it offers and the intrinsic complexity they require. In other words, Linux is great given the problem it solves. Tilck will offer fewer features in exchange for:
- simpler code (by far)
- smaller binary size
- extremely deterministic behavior
- ultra low-latency
- easier development & testing
- extra robustness
In conclusion, while this is still an educational project at the moment, it has been written keeping in mind those goals and it has a test infrastructure that ambitiously tries to be almost enterprise-level (see Testing).
Features
Tilck is a preemptable monolithic *NIX kernel, implementing about ~100 Linux syscalls. At its core, the kernel is not x86-centric even if that was its first target architecture. Almost everything arch-specific is isolated. Because of that, most of kernel's code is not arch-specific and can be already compiled for any architecture to run as part of the unit tests.
i686 support
While the kernel uses a fair amount of legacy hardware like the 8259 PICs for IRQs, the legacy 8254 PIT for the system timer, the legacy 16550 UART for serial communication, the 8042 kb controller, the 8237 ISA DMA, and the Sound Blaster 16 sound card (QEMU only), it has also support for some recent hardware features like SSE, AVX and AVX2 fpu instructions, PAT, i686 sysenter, enumeration of PCI Express devices (via ECAM) and, above all, ACPI support via ACPICA. ACPI is currently used to receive power-button events, to reboot or power-off the machine, and to read the current parameters of machine's batteries (when implemented via ACPI control methods).
Running on physical x86 hardware
The operating system has been regularly tested on physical hardware from its inception by booting it with an USB stick (see the notes below). Test machines include actual i686 machines, older x86_64 machines with BIOS-only firmware, newer x86_64 machines with UEFI+CSM and finally super-recent pure-UEFI machines. For a long time, Tilck's development strictly complied with the following rule: if you cannot test it on real hardware, do not implement it in Tilck. Only recently, that rule has been relaxed a little in order to play with SB16. It is possible that, in the future, there might be a few other drivers that would be tested only on virtual ma
