Hello everyone,
after a long time, I'm pleased to announce the first release of Tilck (version 0.1).
What is Tilck?
Tilck is a x86 monolithic kernel designed to be partially compatible with linux-i686 at binary level,
but it does not aim to re-implement Linux nor to become a desktop operating system. It is, for the
moment, an educational project that I see as 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.
Why trying to be compatible with Linux?
To me, this feature is extremely valuable as it allows the kernel to run third-party software like BusyBox,
VIM, fbDOOM, Lua, TinyCC etc. never written for Tilck: this way, I'm able to test the correctness and the
robustness of my implementation against well-known software and, in case there's a difference, I can
trace the same application/test on both Tilck and Linux and observe where differences start to appear.
To put it in a different way, I believe that writing user code for my own kernel it's like playing a video game
I wrote myself: I'm biased because I know too well how it works under-the-hood and it's less likely I'll
exploit issues. In addition, I value this feature also because it allows a whole class of Linux applications
to work as-it-is, without any porting. And, even when some effort is required to port something to Tilck (e.g.
the Linux feature XY needs to be implemented in the kernel), the payoff for that effort is high, as other
programs requiring the same feature will work, from now on. Still, that doesn't mean it make sense to
re-implement the whole Linux interface; it's a case-by-case thing.
Booting Tilck
Tilck comes with a custom interactive bootloader working both on legacy BIOS and on UEFI systems
as well. The bootloader allows the user to choose the desired video mode, the kernel file itself and to edit
kernel's cmdline. Also, Tilck can be loaded by multiboot-compatible bootloaders like GRUB.
Testing Tilck
Tilck has unit tests, kernel self-tests, system tests (using the syscall interface), and automated
interactive system tests (simulating real user input through QEMU's monitor) all in the same repository,
completely integrated with its build system. In addition to that, there's full code coverage support and
useful scripts for generating HTML reports. Finally, Tilck is fully integrated with the Azure Pipelines CI, which
validates each pushed branch with builds and test runs in a variety of configurations. Kernel's coverage
data is also uploaded to CodeCov.
Hardware support
While the kernel uses a fair amount of legacy hardware like:
- the 8259 PICs for IRQs
- the 8254 PIT for the system timer
- the 16550 UART for serial communication
- the 8042 kb controller
- the 8237 ISA DMA
- the Sound Blaster 16 sound card (QEMU only)
- SSE
- AVX
- AVX 2
- PAT
- sysenter
- enumeration of PCI and PCI Express devices (via ECAM)
- ACPI support via ACPICA
and to read the current parameters of machine's batteries (when implemented via ACPI control
methods).
File systems
Tilck has a simple but full-featured (both soft and hard links, file holes, memory mapping, etc.) ramfs implementation,
a minimalistic devfs implementation, read-only support for FAT16 and FAT32 (used for initrd) allowing memory-mapping
of files, and a sysfs implementation used to provide a full view of ACPI's namespace, the list of all PCI(e) devices and
Tilck's compile-time configuration. Clearly, in order to work with multiple file systems at once, Tilck has a simple VFS
implementation as well.
Future plans
In the long term, depending on how successful the project will be, Tilck might become suitable for
embedded systems. In particular, the plan to port this kernel to ARM existed from the very beginning
of the project. x86 was simply the most convenient architecture for me to start with. Also, it had the
advantage that most laptops and workstations are, indeed, x86 (x86_64) and that's great for testing
purposes and to show it to friends and colleagues. But, given the non-existent presence of x86 in the
SoC world, Tilck's real target architectures are ARM (e.g. Cortex-A) and maybe RISC-V. Because of that,
Tilck can already run today on a QEMU vm with just 4 MB of RAM, even if it's pointless on x86. Finally,
I'd like to make it work on MMU-less CPUs (e.g. ARM Cortex-R series), and enter in the realm of
microcontrollers and hard real-time operating systems. Clearly, the project is far from there, but we're
talking about the long term. Also, the kernel is already modular (has compile-time modules) and it has
been designed from to beginning to depend on a very few HW features. The biggest of them is the MMU.
But, given that Embedded Linux does support MMU-less systems, Tilck might evolve in that direction as well.
For example, it already has vfork(). Therefore, Tilck might become yet-another "linux-tinification" attempt,
with the plus of the BSD license, which is much more permissive than Linux's GPL v2.
Said that, the future remains uncertain and the project might not get enough engagement, as it happens to
most software projects. In that case, I'll continue to maintain it as an educational project with bug-fixes,
polishing and minor features here and there, depending on the amount of time I can spend on it. The
good news is that I've already received good feedback from students attending to operating systems
courses. Therefore, at least in the educational world, I believe this project has some serious hope.
Contributing to the project
While I obviously don't expect hordes of contributors, as anyone who created an open source project,
I hope that someone will take interest in mine, even if by making small contributions. From my
side, I took care to make the whole thing as painless as possible with scripts, tests, documentation etc.
and I'm prepared to spend time helping contributors as well.
Tilck on Github
https://github.com/vvaltchev/tilck
A short presentation video
https://www.youtube.com/watch?v=Ce1pMlZO_mI
Screenshots
