{"id":13628852,"url":"https://github.com/vvaltchev/tilck","last_synced_at":"2025-05-14T04:09:05.764Z","repository":{"id":39458264,"uuid":"53845595","full_name":"vvaltchev/tilck","owner":"vvaltchev","description":"A Tiny Linux-Compatible Kernel","archived":false,"fork":false,"pushed_at":"2025-02-03T06:02:37.000Z","size":10682,"stargazers_count":2430,"open_issues_count":1,"forks_count":105,"subscribers_count":40,"default_branch":"master","last_synced_at":"2025-04-11T00:44:24.843Z","etag":null,"topics":["acpi","assembly","bare-metal","bootloader","embedded-systems","kernel","linux","posix-compatible","uefi","uefi-boot","x86"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-2-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/vvaltchev.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"docs/contributing.md","funding":null,"license":"LICENSE","code_of_conduct":"docs/code_of_conduct.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2016-03-14T10:02:41.000Z","updated_at":"2025-04-08T17:18:56.000Z","dependencies_parsed_at":"2023-10-01T19:57:39.981Z","dependency_job_id":"105ec2ca-c00c-4f98-a009-7cb944daa049","html_url":"https://github.com/vvaltchev/tilck","commit_stats":{"total_commits":5634,"total_committers":16,"mean_commits":352.125,"dds":0.02431664891728791,"last_synced_commit":"77093bdd0ee1a9255243c598fc5a55182c5f9a51"},"previous_names":[],"tags_count":33,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vvaltchev%2Ftilck","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vvaltchev%2Ftilck/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vvaltchev%2Ftilck/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/vvaltchev%2Ftilck/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/vvaltchev","download_url":"https://codeload.github.com/vvaltchev/tilck/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254070013,"owners_count":22009559,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["acpi","assembly","bare-metal","bootloader","embedded-systems","kernel","linux","posix-compatible","uefi","uefi-boot","x86"],"created_at":"2024-08-01T22:00:58.487Z","updated_at":"2025-05-14T04:09:00.737Z","avatar_url":"https://github.com/vvaltchev.png","language":"C","readme":"\u003cp align=\"center\"\u003e\n   \u003cimg src=\"http://vvaltchev.github.io/tilck_imgs/v2/tilck-logo-v5.png\" alt=\"Tilck - A Tiny Linux-Compatible Kernel\"\u003e\n\u003c/p\u003e\n\n\nWhat \\ Arch         | i386                 | riscv64      | x86_64 (build)\n--------------------|----------------------|--------------|------------------\nTests               | [![Build Status](https://vkvaltchev.visualstudio.com/Tilck/_apis/build/status%2FTilck%20i386?branchName=master)](https://vkvaltchev.visualstudio.com/Tilck/_build/latest?definitionId=15\u0026branchName=master) | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FTilck%20riscv64?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=14\u0026branchName=master) | [![Build Status](https://vkvaltchev.visualstudio.com/Tilck/_apis/build/status%2FTilck%20x86_64?branchName=master)](https://vkvaltchev.visualstudio.com/Tilck/_build/latest?definitionId=16\u0026branchName=master)\nToolchain debian    | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Fdebian%20i386?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=19\u0026branchName=master) | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Fdebian%20riscv64?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=20\u0026branchName=master) | N/A\nToolchain fedora    | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Ffedora%20i386?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=21\u0026branchName=master) | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Ffedora%20riscv64?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=22\u0026branchName=master) | N/A\nToolchain archlinux | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Farch%20i386?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=23\u0026branchName=master) | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Farch%20riscv64?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=24\u0026branchName=master) | N/A\nToolchain openSUSE  | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Fopensuse%20i386?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=25\u0026branchName=master) | [![Build Status](https://dev.azure.com/vkvaltchev/Tilck/_apis/build/status%2FToolchain%2Fopensuse%20riscv64?branchName=master)](https://dev.azure.com/vkvaltchev/Tilck/_build/latest?definitionId=26\u0026branchName=master) | N/A\n\n[![codecov](https://codecov.io/gh/vvaltchev/tilck/branch/master/graph/badge.svg)](https://codecov.io/gh/vvaltchev/tilck) [![License](https://img.shields.io/badge/License-BSD%202--Clause-orange.svg)](https://opensource.org/licenses/BSD-2-Clause)\n\n\u003ca href=\"https://youtu.be/Ce1pMlZO_mI\"\u003e\n   \u003cimg\n      align=\"right\"\n      src=\"http://vvaltchev.github.io/tilck_imgs/v2/main2-smaller-70p-yt.png\"\n      alt=\"Tilck\"\n   \u003e\n\u003c/a\u003e\n\nContents\n----------------------------------------\n* [Overview](#overview)\n  - [What is Tilck?](#what-is-tilck)\n    * [Future plans](#future-plans)\n  - [What Tilck is NOT ?](#what-tilck-is-not-)\n    * [Tilck vs Linux](#tilck-vs-linux)\n* [Features](#features)\n   - [i686 support](#i686-support)\n   - [riscv64 support](#riscv64-support)\n   - [File systems](#file-systems)\n   - [Processes and signals](#processes-and-signals)\n   - [I/O](#io)\n   - [Console](#console)\n   - [Userspace applications](#userspace-applications)\n* [Booting Tilck](#booting-tilck)\n  - [Tilck's bootloader](#tilcks-bootloader)\n  - [3rd-party bootloaders](#3rd-party-bootloaders)\n    * [Grub support](#grub-support)\n* [Documentation and HOWTOs](#documentation-and-howtos)\n  - [Building Tilck](#building-tilck)\n  - [Testing Tilck](#testing-tilck)\n  - [Debugging Tilck](#debugging-tilck)\n    * [Tilck's debug panel](#tilcks-debug-panel)\n* [A comment about user experience](#a-comment-about-user-experience)\n* [FAQ](#faq)\n\nOverview\n----------------------------------------\n\n\u003cp align=\"center\"\u003e\n    \u003cimg src=\"http://vvaltchev.github.io/tilck_imgs/v2/overview.png\" border=\"0\"\u003e\n\u003c/p\u003e\n\n### What is Tilck?\n`Tilck` is an educational *monolithic* kernel designed to be Linux-compatible at\nbinary level. It runs on i686 and RISCV64 at the moment. Project's small-scale\nand simple design makes it the **perfect playground** for playing in kernel mode\nwhile retaining the ability to compare how the *very same* *usermode bits* run on\nthe Linux kernel as well. That's a **rare feature** in the realm of educational\nkernels. Because of that, building a program for Tilck requires just a `gcc-musl`\ntoolchain from [bootlin.com](https://toolchains.bootlin.com). Tilck has **no need**\nto have its own set of custom written applications, like most educational kernels do.\nIt just runs mainstream Linux programs like the **BusyBox** suite. While the\nLinux-compatibility and the monolithic design might seem a limitation from the OS\nresearch point of view, on the other side, such design bring the whole project much\ncloser to *real-world* applications in the future, compared to the case where some\nserious (or huge) effort is required to port pre-existing software on it. Also, nothing\nstops Tilck from implementing custom non-Linux syscalls that aware apps might take\nadvantage of.\n\n#### Future plans\nIn the long term, `Tilck` might become widespread for **embedded systems** on\nwhich a fully deterministic and ultra low-latency system is required. \nWith a fair amount of luck, `Tilck` might be able to fill the gap between\n*Embedded Linux* and typical real-time operating systems like *FreeRTOS* or\n*Zephyr*. The kernel already runs on RISCV64 and at some point it will be ported\nto the `ARM` family. It might be adapted to run on MMU-less CPUs as well. Tilck\nwould be a perfect fit for such use cases because consuming a tiny amount of RAM\nhas always been a key point in Tilck's design. Indeed, the kernel can boot and\nrun on a QEMU machine with just 3 MB of memory *today*. \n\nIn addition to that, adding a basic support for networking and storage is part of\nthe plans even if details have not been defined yet. Networking support might be\nlimited to UDP + IP (at least at the beginning) and usable on a limited set of\nnetwork cards. The same applies for storage: not all kinds of block devices will\nbe supported, and a few filesystems (maybe just fat32 and ext2) will implemented\nin the kernel. The support for FUSE filesystems will be considered.\n\nOne major milestone for the project will be to support both networking and storage\nfor a specific SoC like Raspberry Pi 3 (or 4) but that could possibly happen only\nafter Tilck has been ported to ARM64.\n\n### What Tilck is NOT ?\n * An attempt to re-write and/or replace the Linux kernel. Tilck is a completely\ndifferent kernel that has a *partial* compatibility with Linux just in order to\ntake advantage of its programs and toolchains. Also, that helps a lot to validate\nits correctness: if a program works correctly on Linux, it must work the same way\non Tilck as well (minus not-implemented features). **But**, having a fair amount\nof Linux programs working on it, is just a *starting point*: with time, Tilck\nwill evolve in a different way and it will have its own unique set of features as\nwell.\n\n* A kernel suitable for a *desktop* operating system. No X server works on Tilck,\nnot only because a considerable amount of extra features will be required for that,\nbut because working in that direction is *completely outside* of project's goals.\nSee also: https://github.com/vvaltchev/tilck/discussions/81\n\n#### Tilck vs Linux\nTilck is fundamentally different from Linux as it **does not** aim to target\nmulti-user server nor desktop machines, at all because that would be pointless:\nLinux is **not** big \u0026 complex because of a *poor* implementation, but because\nof the incredible amount of features it offers and the *intrinsic* complexity they\nrequire. In other words, **Linux is great** given the problem it solves. Tilck will\noffer *fewer* features in exchange for:\n\n - simpler code (by far)\n - smaller binary size\n - extremely deterministic behavior\n - ultra low-latency\n - easier development \u0026 testing\n - extra robustness\n\nIn conclusion, while this is still an *educational* project at the moment, it has been\nwritten keeping in mind those goals and it has a test infrastructure that ambitiously\ntries to be almost *enterprise-level* (see [Testing](#testing-tilck)).\n\nFeatures\n----------------------------------------\n\nTilck is a preemptable monolithic *NIX kernel, implementing about ~100 Linux\nsyscalls. At its core, the kernel is not x86-centric even if that was its first\ntarget architecture. Almost everything arch-specific is isolated. Because of that,\nmost of kernel's code is not arch-specific and can be already compiled for any\narchitecture to run as part of the unit tests.\n\n#### i686 support\nWhile the kernel uses a fair amount of **legacy hardware** like the 8259 PICs for\nIRQs, the legacy 8254 PIT for the system timer, the legacy 16550 UART for serial\ncommunication, the 8042 kb controller, the 8237 ISA DMA, and the Sound Blaster\n16 sound card (QEMU only), it has also support for some **recent hardware** features\nlike SSE, AVX and AVX2 fpu instructions, PAT, i686 sysenter, enumeration of PCI Express\ndevices (via ECAM) and, above all, **ACPI** support via ACPICA. ACPI is currently\nused to receive power-button events, to reboot or power-off the machine, and to\nread the current parameters of machine's batteries (when implemented via ACPI control\nmethods).\n\n##### Running on physical x86 hardware\nThe operating system has been regularly tested on physical hardware from its inception\nby booting it with an USB stick (see the notes below). Test machines include actual i686\nmachines, older x86_64 machines with BIOS-only firmware, newer x86_64 machines with\nUEFI+CSM and finally super-recent pure-UEFI machines. For a long time, Tilck's development\nstrictly complied with the following rule: *if you cannot test it on real hardware, do not\nimplement it in Tilck*. Only recently, that rule has been relaxed a little in order to play\nwith SB16. It is possible that, in the future, there might be a few other drivers that\nwould be tested only on virtual machines: their development is justified by the educational\nvalue it will bring to the operating system and the infrastructure built for them will be\nreused for other drivers of the same kind. **But** that will *never* become a common practice.\nTilck is designed to work on real hardware, where any kind of weird things happen. Being\nreliable there is *critical* for Tilck's success.\n\n#### riscv64 support\n\nTilck's support for the riscv64 architecture mainly focuses on embedded applications. Tilck runs\nin RV64 supervisor mode (Smode), uses SV39 three-level page table virtual memory, and supports\nuser space floating point.\n\n##### riscv64 hardware peripheral support\n\nThe riscv64 architecture adopts a device tree-based driver model and in Tilck and all\nhardware information is obtained from the device tree transmitted by the bootloader. Therefore,\nTilck's riscv kernel code does not have any board-level description code. The system timer\n(for ticks) invokes the SBI monitor program (openSBI) through RISCV SBI interface instead of\nimplementing a driver in the kernel. The system RTC clock is implemented using a very simple\ngoldfish virtual RTC driver, which works only on the QEMU virtual platform.\n\nTilck on RISCV does *not* implement typical PC peripherals such as keyboards: for both input\nand output serial ports have to be used (which is enough for most embedded applications).\nThe most common `ns16550` UART driver has been implemented. To better manage the multi-level\nnested interrupt architecture common in embedded chips, Tilck on RISCV implements a simplified\nframework similar to the idea of Linux IRQ domains. The most common INTC and PLIC interrupt\ncontroller drivers are supported.\n\n##### board support\n\nTilck on RISCV64 implements a very simple BSP framework, which can be managed by setting environment\nvariable `BOARD` to build a image of the corresponding board. Currently, Tilck supports only the\n[Sipeed licheerv-nano] board and the qemu-virt virtual board (set by default). QEMU-virt has the\nframebuffer mode enabled by default, while having FB support on `licheerv-nano` requires patching\nthe original bootloader provided by Sipeed.\n\n[Sipeed licheerv-nano]: https://wiki.sipeed.com/hardware/en/lichee/RV_Nano/1_intro.html\n\n#### File systems\nTilck has a simple but full-featured (both soft and hard links, file holes, memory\nmapping, etc.) **ramfs** implementation, a minimalistic **devfs** implementation,\nread-only support for FAT16 and **FAT32** (used for initrd) allowing memory-mapping\nof files, and a **sysfs** implementation used to provide a full view of **ACPI's**\n**namespace**, the list of all PCI(e) devices and Tilck's compile-time configuration.\nClearly, in order to work with multiple file systems at once, Tilck has a simple\n**VFS** implementation as well. **Note**: there is no support for block devices in Tilck\nyet, so everything is in-memory.\n\n#### Processes and signals\nWhile Tilck uses internally the concept of thread, multi-threading is not currently\nexposed to userspace (kernel threads exist, of course). Both `fork()` and `vfork()` are\nproperly implemented and copy-on-write is used for fork-ed processes. The `waitpid()`\nsyscall is fully implemented (which implies process groups etc.). The support for\nPOSIX signals is partial: custom signal handlers are supported using the `rt_sigaction()`\ninterface, but most of the SA_* flags are not supported and handlers cannot interrupt\neach other, yet. `rt_sigprocmask()`, `sys_rt_sigpending()`, `sys_rt_sigsuspend()`\nwork as expected, as well as special signals like SIGSTOP, SIGCONT and SIGCHLD.\nFor more details, see the [syscalls] document.\n\nOne interesting feature in this area deserves a special mention: despite the lack of\nmulti-threading in userspace, Tilck has full support for TLS (thread-local storage) via\n`set_thread_area()`, because `libmusl` requires it, even for classic single-threaded\nprocesses.\n\n#### I/O\nIn addition to the classic `read()` and `write()` syscalls, Tilck supports vectored I/O\nvia `readv()` and `writev()` as well. In addition to that, non blocking I/O, `select()`\nand `poll()` are supported too. Fortunately, no program so far needed `epoll` :-)\n\n#### Console\nTilck has a console supporting more than 90% of Linux's console's features. It works\nin the same way (using layers of abstraction) both in text mode and in framebuffer mode.\nThe effort to implement such a powerful console was driven by the goal to make **Vim** work\nsmoothly on Tilck, with syntax highlighting etc. While it's true that such a thing has a\nlittle to do with \"proper\" kernel development, being able to run a \"beast\" like Vim on a\nsimple kernel like Tilck, is a great achievement by itself because it shows that Tilck\ncan run correctly programs having a fair amount of complexity.\n\n#### Userspace applications\nTilck can run a fair amount of console applications like the **BusyBox** suite,\n**Vim**, **TinyCC**, **Micropython**, **Lua**, and framebuffer applications like\n**fbDOOM** just for fun, despite that being completely out of project's scope.\nCheck project's [wiki page] for more info about the software that can run on\nTilck.\n\n[syscalls]: docs/syscalls.md\n[wiki page]: https://github.com/vvaltchev/tilck/wiki\n\nBooting Tilck on x86\n----------------------------------------\n\n### Tilck's bootloader\n`Tilck` comes with an interactive bootloader working both on legacy BIOS and on UEFI\nsystems as well. The bootloader allows the user to choose the desired video\nmode, the kernel file itself and to edit kernel's cmdline.\n\n![Tilck's bootloader](http://vvaltchev.github.io/tilck_imgs/v2/bootloader.png)\n\n### 3rd-party bootloaders (x86)\n`Tilck` can be loaded by any bootloader supporting `multiboot 1.0`. For example,\nqemu's built-in bootloader works perfectly with `Tilck`:\n\n    qemu-system-i386 -kernel ./build/tilck -initrd ./build/fatpart\n\nActually that way of booting the kernel is used in the system tests. A shortcut\nfor it is:\n\n    ./build/run_multiboot_qemu\n\n#### Grub support\n`Tilck` can be easily booted with GRUB. Just edit your `/etc/grub.d/40_custom`\nfile (or create another one) by adding an entry like:\n\n```\nmenuentry \"Tilck\" {\n    multiboot \u003cPATH-TO-TILCK-BUILD-DIR\u003e/tilck\n    module --nounzip \u003cPATH-TO-TILCK-BUILD-DIR\u003e/fatpart\n    boot\n}\n```\nAfter that, just run `update-grub` as root and reboot your machine.\n\nDocumentation and HOWTOs\n--------------------------\n\nProject's main documentation can be found in the `docs/` directory. However,\n[Tilck's wiki](https://github.com/vvaltchev/tilck/wiki) can be used to\nnavigate through those documention files with the addition of much extra content\nlike screenshots. Here below, instead, there's a quick *starter* guide, focusing\non the most common scenarios.\n\n### Building Tilck\nThe project supports a fair amount of build configurations and customizations\nbut building using its default configuration can be described in just a few\nsteps. The *only* true requirement for building Tilck is having a Linux\nx86_64 host system or Microsoft's `WSL`. Steps:\n\n* Enter project's root directory.\n* Build the toolchain (just the first time) with: `./scripts/build_toolchain`\n* Compile the kernel and prepare the bootable image with: `make`\n\nAt this point, there will be an image file named `tilck.img` in the `build`\ndirectory. The easiest way for actually trying `Tilck` at that point is to run:\n`./build/run_qemu`.\n\n#### Running it on physical hardware\nThe `tilck.img` image is, of course, bootable on physical machines as well,\nboth on UEFI systems and on legacy ones. Just flush the image file with `dd`\nto a usb stick and reboot your machine.\n\n#### Other configurations\nTo learn much more about how to build and configure Tilck, check the [building]\nguide in the `docs/` directory.\n\n[building]: docs/building.md\n\n### Testing Tilck\nTilck has **unit tests**, **kernel self-tests**, **system tests** (using the\nsyscall interface), and **automated interactive system tests** (simulating real\nuser input through QEMU's monitor) all in the same repository, completely\nintegrated with its build system. In addition to that, there's full code\ncoverage support and useful scripts for generating HTML reports (see the\n[coverage] guide). Finally, Tilck is fully integrated with the [Azure Pipelines]\n[CI], which validates each pushed branch with builds and test runs in a variety\nof configurations. Kernel's coverage data is also uploaded to [CodeCov]. Below,\nthere are some basic instructions to run most of Tilck's tests. For the whole\nstory, please read the [testing] document.\n\n[Azure Pipelines]: https://azure.microsoft.com/en-us/services/devops/pipelines\n[CI]: https://en.wikipedia.org/wiki/Continuous_integration\n[CodeCov]: https://codecov.io\n\n#### Running Tilck's tests\nRunning Tilck's tests is extremely simple: it just requires to have `python 3`\ninstalled on the machine. For the **self-tests** and the classic\n**system tests**, run:\n\n    \u003cBUILD_DIR\u003e/st/run_all_tests -c\n\nTo run the **unit tests** instead:\n\n   * Install the [googletest] library (once) with:\n     `./scripts/build_toolchain -s build_gtest build_gmock`\n\n   * Build the unit tests with: `make gtests`\n\n   * Run them with: `\u003cBUILD_DIR\u003e/gtests`\n\nTo learn much more about Tilck's tests in general and to understand how to run\nits *interactive* system tests as well, read the [testing] document.\n\n[testing]: docs/testing.md\n[googletest]: https://github.com/google/googletest\n\n### Debugging Tilck\nWith `QEMU`'s integrated `GDB` server, it's possible to debug the Tilck kernel\nwith GDB almost as if it were a regular process. It just gets tricky when\ncontext switches happen, but GDB cannot help with that. To debug it with GDB,\nfollow the steps:\n\n  - (Optional) Prepare a debug build of Tilck, for a better debugging experience.\n\n  - Run Tilck's VM with: `./build/run_qemu` but, remain at the bootloader\n    stage.\n\n  - In a different terminal, run: `gdb ./build/tilck_unstripped`.\n\n  - In GDB, run: `target remote :1234` to connect to QEMU's gdb server.\n\n  - Set one or more breakpoints using commands like: `break kmain`.\n\n  - Type `c` to allow execution to continue and boot the OS by pressing ENTER\n    in the bootloader.\n\nIn order to make the debugging experience better, Tilck comes with a set of\n**GDB scripts** (see `other/gdb_scripts`). With them, it's super-easy to list\nall the tasks on the system, the handles currently opened by any given process\nand more. In order to learn how to take advantage of those GDB scripts and anything\nelse related to debugging the Tilck project, check the [debugging] document.\n\n[debugging]: docs/debugging.md\n\n#### Tilck's debug panel\n\n\u003cimg align=\"right\"\nsrc=\"http://vvaltchev.github.io/tilck_imgs/v2/screenshots/dp04.png\"\nalt=\"Tilck's debug panel\" width=\"50%\" height=\"50%\"\u003e\n\nDebugging Tilck with GDB while it's running inside a VM is very convenient, but\nin other cases (e.g. Tilck on real hardware) we don't have GDB support. In\naddition to that, even when the kernel is running inside a VM, there are some\nfeatures that are just much more convient to expose directly from the kernel\nitself rather than through GDB scripts. One way to expose kernel info to\nuserspace is to use `sysfs`, but that's not necessarily the most convenient way\nfor everything (still, Tilck does have [sysfs] implementation), especially when\n*interaction* with the kernel itself is needed for debugging purposes. To help\nin those cases, a *debug panel* has been introduced inside Tilck itself. It\nstarted as something like Linux's [Magic SysRq] which evolved in a sort of TUI\napplication with debug info plus tracing capabilities for user processes. In the\nfuture, it will support some proper debugging features as well. To learn more\nabout it, check the the [debugging] document.\n\n[sysfs]: https://github.com/vvaltchev/tilck/wiki/Tilck's-sysfs\n[Magic SysRq]: https://en.wikipedia.org/wiki/Magic_SysRq_key\n\nA comment about user experience\n----------------------------------\n\nTilck particularly distinguishes itself from many open source projects in one\nway: it really cares about the **user experience** (where \"user\" means\n\"developer\"). It's not the typical super-cool low-level project that's insanely\ncomplex to build and configure; it's not a project requiring 200 things to be\ninstalled on the host machine. Building such projects may require hours or even\ndays of effort (think about special configurations e.g. building with a\ncross-compiler). Tilck instead, has been designed to be trivial to build and\ntest even by inexperienced people with basic knowledge of Linux. It has a\nsophisticated script for building its own toolchain that works on all the major\nLinux distributions and a powerful CMake-based build system. The build of Tilck\nproduces an image ready to be tested with QEMU or written on a USB stick. (To\nsome degree, it's like what the `buildroot` project does for Linux, but it's\nmuch simpler.) Finally, the project includes also scripts for running Tilck\non QEMU with various configurations (BIOS boot, UEFI boot, direct (multi-)boot\nwith QEMU's `-kernel` option, etc.).\n\n#### Motivation\nThe reason for having the above mentioned features is to offer its users and\npotential contributors a really **nice** experience, avoiding any kind of\nfrustration. Hopefully, even the most experienced engineers will enjoy a zero\neffort experience. But it's not all about reducing the frustration. It's also\nabout _not scaring_ students and junior developers who might be just curious to\nsee what this project is all about and maybe eager to write a simple program for\nit and/or add a couple of `printk()`'s here and there in their fork. Hopefully,\nsome of those people *just playing* with Tilck might actually want to contribute\nto its development.\n\nIn conclusion, even if some parts of the project itself are be pretty complex,\nat least building and running its tests **must be** something anyone can do.\n\n[coverage]: docs/coverage.md\n\nFAQ\n---------------------\n\nHere below, there is a list of *frequently* asked questions.\nThis list is *not* supposed to be exaustive and it will change over time.\nFor the *full list* of questions on Tilck, check the [Q \u0026 A page] in the [Discussions] section instead.\n\n[Q \u0026 A page]: https://github.com/vvaltchev/tilck/discussions/categories/q-a\n[Discussions]: https://github.com/vvaltchev/tilck/discussions\n\n- [Why Tilck does not have the feature/abstraction XYZ like other kernels do?](https://github.com/vvaltchev/tilck/discussions/83)\n\n- [Can Tilck be used to build other projects on the top of it?](https://github.com/vvaltchev/tilck/discussions/185)\n\n- [Why having support for FAT32?](https://github.com/vvaltchev/tilck/discussions/85)\n\n- [Why keeping the initrd mounted?](https://github.com/vvaltchev/tilck/discussions/86)\n\n- [Why using 3 spaces as indentation?](https://github.com/vvaltchev/tilck/discussions/88)\n\n- [Why many commit messages are so short?](https://github.com/vvaltchev/tilck/discussions/89)\n\n- [Can a lightweight X server run on Tilck today?](https://github.com/vvaltchev/tilck/discussions/81)\n\n- [Compiling Tilck with TCC \u0026 self-hosting?](https://github.com/vvaltchev/tilck/discussions/93)\n","funding_links":[],"categories":["C","Active","Open Source Operating Systems"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvvaltchev%2Ftilck","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fvvaltchev%2Ftilck","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fvvaltchev%2Ftilck/lists"}