# RTEMS: a real-time executive for embedded multiprocessor systems > RTEMS is a C real-time operating system kernel for embedded targets, with SMP scheduling, a family of locking protocols, several file systems and board support packages. This repository on GitHub is a mirror, and the real project lives on GitLab. **RTEMS/rtems** — Mirror only see https://gitlab.rtems.org/rtems/rtos/rtems - Repository: https://github.com/RTEMS/rtems - Website: https://gitlab.rtems.org/rtems/rtos/rtems - Stars: 771 · Forks: 418 - Language: C - License: NOASSERTION - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/rtems-rtems ## A kernel, not a distribution, for targets with a fixed size budget RTEMS describes itself as a real-time executive, in other words a kernel, that gives embedded applications a high performance environment. It is written in C, which is the expected language when the target has kilobytes rather than gigabytes of memory. The feature list in the README is wide but specific: standards based user interfaces, multitasking, event driven priority based preemptive scheduling, responsive interrupt management, dynamic memory allocation, dynamic code loading using run-time link editing, and intertask communication and synchronisation. What makes it more than a teaching kernel is the multiprocessor story. Both homogeneous and heterogeneous multiprocessor systems are supported, and symmetric multiprocessing comes with a cluster scheduler described as a job level fixed priority scheduler (EDF) with support for one-to-one and one-to-all thread to processor affinities. For teams porting a design from a single core to a cluster, the affinity and scheduler configuration is where most of the real work sits, and it is present here rather than left to the application. ## The locking protocols are the part you have to read the docs for Any real-time kernel that lets threads share resources will deadlock or invert priorities if the locking discipline is left to chance, so RTEMS builds a set of protocols into the kernel itself. The README lists locking protocols with transitive priority inheritance, priority ceiling, MRsP and OMIP, and priority inheritance also appears as a standalone feature. What that means in practice is that a thread blocked on a mutex can have its priority raised to that of the holder, which is the classic fix for priority inversion. Ceiling protocols instead bound the priority a lock may grant in advance, and the other two entries cover recursive and priority inheritance variants. This is a real strength and also a real cost: the choice of protocol is a configuration decision with measurable timing consequences, and the README lists these as link-time configurable schedulers, so the answer is not something you can change by flipping a runtime flag. The POSIX 1003.1 compliance guide in the online documentation is the place to check which of these are exposed through the standard interfaces your application will use. ## What the repository tree tells you about the layering The top level of the repository is where the architecture becomes visible, since the source itself is not documented in the README beyond the feature list. The cpukit directory holds the kernel and the portable core of the system, bsps and the rtems-bsps directory hold the board support packages, spec holds the API specification, and testsuites contains the test suites. The make directory and the top level waf script with its wscript file belong to the build machinery, while yaml and the .gitlab directory carry configuration, and gccdeps.py and _clang-format sit alongside the Doxyfile that generates the API documentation. Two things follow. First, the split between cpukit and bsps is the split between portable kernel and target specific glue, which is what decides how expensive a new target port is. Second, the presence of spec and testsuites says the project treats the API as a contract that is checked, and the Doxyfile and the CPUKit doxygen pages referenced in the README are how you read that contract before writing code against it. ## File systems and drivers are where the board specific work happens The README lists file systems covering IMFS, FAT, RFS, JFFS and NSFv4 with LibBSD, and drivers for I2C and SPI, with LibBSD adding NIC, USB, SD/MMC and Framebuffer support. For an embedded target this is the difference between a kernel you can evaluate quickly and one you cannot, because every one of those items has to be enabled, configured and validated against real hardware before it does anything useful. The hierarchy is clear from the ordering: IMFS and FAT are in the kernel, NSFv4 arrives with LibBSD, and the hardware-facing parts sit in the board support packages rather than in cpukit. A team that has standardised on FAT for removable media, or on JFFS for flash, can read the documentation and find the corresponding implementation instead of writing a driver from scratch. The dependency on LibBSD for the richer networking and storage stack is worth noting in advance, since it means part of the stack arrives as an imported system component rather than as original RTEMS code. ## This GitHub repository is a mirror, and the build lives in waf The repository description on GitHub says it is a mirror only and points at the project on GitLab, and the README repeats that project git repositories are located under the GitLab host. The consequence is simple but easy to get wrong: the canonical history, the issue tracker and the release process live elsewhere, and the README points to that location rather than to anything in this tree. The README also states that the version number for releases is located in the VERSION file if present, and the GitHub repository has no GitHub releases, so the release trail has to be followed on the project's own hosting. For getting the source and the documentation, the README lists the project site, the online documentation, the CPUKit doxygen pages, the POSIX compliance guide, the Discourse user forum, the Discord support channel, and the users and devel mailing lists. The build system is visible in the tree through the waf script, the wscript file and the make directory, but the README does not lay out a step by step installation procedure, so the configuration details belong to the online documentation rather than to this file. ## A friendly license that GitHub cannot classify, and a very recent push The licence line in the repository metadata reads as a custom licence that GitHub cannot classify, with the pointer to the LICENSE file, and the top level tree contains a LICENSE.md alongside a CODEOWNERS file and the .gitlab configuration. The README describes the project as open source with a friendly user licence, which is a claim you can only evaluate by reading the licence text itself, so anyone planning a commercial deployment should do that before assuming the MIT style terms they might expect from other C projects. On maintenance, the last push was on 2026-10-20 and the repository is not archived, so the tree does move. Version numbering comes from the VERSION file when it is present, and the README does not describe a support policy for older releases or a long term support branch, which is the kind of question a certification schedule would need answered before a port is frozen. ## Conclusion RTEMS suits teams already building embedded systems that need POSIX style interfaces, deterministic scheduling and SMP, and the fact that the scheduler and locking protocol choices are link time configurable makes it a good fit for research and for certification oriented work. It is the wrong tool for a general purpose server, for anything that expects a large third party package ecosystem, or for a team that needs the source tree to be the single source of truth, because this GitHub repository is a mirror only. Before adopting it, pull from the GitLab repository listed in the README, confirm the board support package for your target CPU in the bsps directory, and read the POSIX 1003.1 compliance guide to see which interfaces you can rely on. ## FAQ ### What is RTEMS and who is it for? RTEMS is a real-time executive written in C that provides a real-time environment for embedded applications, with multitasking, preemptive priority based scheduling and support for homogeneous and heterogeneous multiprocessor systems. It is aimed at developers of embedded systems with real-time and resource constrained requirements. ### Does RTEMS support symmetric multiprocessing? Yes. The README lists SMP with a cluster scheduling described as a job level fixed priority scheduler (EDF) with support for one-to-one and one-to-all thread to processor affinities, and it also lists link-time configurable schedulers. The schedulers are configured at link time rather than switched at runtime. ### How does RTEMS avoid priority inversion? The kernel includes priority inheritance as a feature, and the README lists locking protocols with transitive priority inheritance, priority ceiling, MRsP and OMIP. These are kernel level protocols rather than conventions left to application code. ### Which file systems and drivers does RTEMS provide? The README lists IMFS, FAT, RFS, JFFS and NSFv4 with LibBSD as file systems, and drivers for I2C and SPI, with LibBSD adding NIC, USB, SD/MMC and Framebuffer support. Board specific hardware support lives in the board support packages. ### Where is the canonical source for RTEMS, and how do I find the version? This GitHub repository is a mirror only, and the README states that project git repositories are located on the GitLab host, with online documentation available at the documented site. The version number for releases is located in the VERSION file if present. ## Sources - [Issues](https://github.com/RTEMS/rtems/issues) - [Project website](https://gitlab.rtems.org/rtems/rtos/rtems) - [README](https://github.com/RTEMS/rtems/blob/main/README.md) - [RTEMS/rtems on GitHub](https://github.com/RTEMS/rtems) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rtems-rtems