[More software will be published as we deem it ready for sharing until eventually all of Sparrow (software and hardware designs) will be available.]
Most of CantripOS is written in Rust. The Rust crates reside in the apps/system/components directory of this git repository. CantripOS system services are structured as CAmkES components. Target-platform-dependent services are tagged, e.g. [sparrow-only] for services that are only supported on apps/system/platforms/sparrow.:
- DebugConsole: a command line interface intended for debug builds that also handles logging to the console
- MailboxDriver: a driver for the Mailbox interface used to communicate betwen the security and management cores [sparow-only]
- MemoryManager: the service that supports dynamic memory / object management
- MlCoordinator: a service that manages running ML jobs [requires ML accelerator support that is sparrow-only]
- ProcessManager: the service that creates & manages execution of applications
- SDKRuntime: the service that handles application runtime requests
- SecurityCoordinator: the service that provides an interface to the security core (using the MailboxDriver)
- TimerService: a service that provides timers to system services & applications [requires hardware timer support]
- UARTDriver: a driver for the UART on the management core [sparrow-only]
The set of system services depends on the target platform. At the moment two platforms are buildable: sparrow and rpi3 (Raspberry Pi BCM2837 running in 64-bit mode). The sparrow platform is not currently useful other than for reference as building it requires toolchain & simulator support that is not yet released. The rpi3 platform is the intended target platform for public consumption. Contribution of additional platform support is welcomed (e.g. an rpi3 timer driver would enable use of the TimerService).
All platform-supported CantripOS services are included in both debug and release builds. Production builds replace the DebugConsole with a more limited interface and drop the UART driver when there is no serial console. The SDKRuntime is more a proof of concept than anything else. There are test applications written in C and Rust in the apps tree that exercise the experimental api. Production systems may have their own SDK and associated runtime tailored to their needs.
In addition to the system services described above, common/shared code is in the cantrip-os-common directory/crate:
- allocator: a heap allocator built on the linked-list-allocator crate
- camkes: support for writing CAmkES components in Rust
- capdl: support for reading the capDL specification generated by capDL-tool
- copyregion: a helper for temporarily mapping physical pages into a thread's VSpace
- cspace-slot: an RAII helper for the slot-allocator
- logger: seL4 integration with the Rust logger crate
- model: support for processing capDL; used by the cantrip-os-rootserver
- panic: an seL4-specific panic handler
- sel4-config: build glue for seL4 kernel configuration
- sel4-sys: seL4 system interfaces & glue
- slot-allocator: an allocator for slots in the top-level CNode
The allocator and logger crates are used by both system services and applications.
We are still working out the versioning of the crates. At the moment development is done entirely from source code and is still very active so there has been no benefit to rev'ing crate versions.