|
1 | 1 |
|
2 | 2 | # Operating System Abstraction Layer (OSAL) |
3 | 3 |
|
4 | | -## References |
| 4 | +The OSAL provides a portable interface to operating system services (tasks, files, mutexes, queues, and system resources), enabling F Prime applications to run on multiple platforms without source code changes. |
5 | 5 |
|
6 | | -- [OSAL SDD](https://github.com/nasa/fprime/blob/devel/Os/docs/sdd.md) |
7 | | -- [Generic Services SDD](https://github.com/nasa/fprime/blob/devel/Os/Generic/docs/sdd.md) |
8 | | -- [How-To: Implement an OSAL](https://github.com/nasa/fprime/blob/devel/docs/how-to/implement-osal.md) |
| 6 | +For full documentation including architecture, API details, and implementation guidance, see the [OSAL SDD](https://github.com/nasa/fprime/blob/devel/Os/docs/sdd.md). |
9 | 7 |
|
10 | | -## Overview |
11 | | - |
12 | | -The Operating System Abstraction Layer (OSAL) provides a portable interface to operating system services, enabling F Prime applications to run on multiple operating systems without source code modifications. All platform-specific functionality (threads, files, synchronization, system resources) is accessed through the OSAL rather than through direct OS calls. The OSAL ships with a POSIX backend for Linux/macOS and a stub backend for platforms without full OS support. Additional backends (Zephyr, VxWorks, FreeRTOS) are available through community platform support packages. |
13 | | - |
14 | | -### Concurrency |
15 | | - |
16 | | -The OSAL provides the following concurrency primitives: |
17 | | - |
18 | | -- **Tasks** — Thread creation, joining, and lifecycle management. Tasks support start/stop callbacks and can be delayed for a specified duration. Tasks are the execution context for active components. |
19 | | -- **Mutexes** — Mutual-exclusion locks for protecting shared data. An RAII scope lock helper is provided for automatic acquire/release within a scope. |
20 | | -- **Condition Variables** — Signaling mechanism paired with mutexes for producer/consumer patterns and other synchronization needs. |
21 | | -- **Queues** — Inter-task message passing with configurable depth, optional priority support, and blocking modes. Queues are the underlying mechanism for active component message dispatch. |
22 | | - |
23 | | -### File System |
24 | | - |
25 | | -The OSAL provides file and directory access: |
26 | | - |
27 | | -- **Files** — Open, read, write, seek, flush, and CRC computation on individual files. |
28 | | -- **Directories** — Open, iterate, and create directory entries. |
29 | | -- **File System Operations** — Higher-level operations including remove, move/rename, copy, stat, free space queries, and working directory management. |
30 | | - |
31 | | -### System Resources |
32 | | - |
33 | | -The OSAL provides access to system-level information: |
34 | | - |
35 | | -- **Raw Time** — Access to the system clock for measuring time intervals. |
36 | | -- **CPU** — CPU count and per-CPU usage statistics. |
37 | | -- **Memory** — System memory usage statistics. |
38 | | - |
39 | | -### Console |
40 | | - |
41 | | -The console service provides a mechanism for writing messages to the system console output, used primarily for text event logging and diagnostic output. |
42 | | - |
43 | | -### Generic Services |
44 | | - |
45 | | -In addition to the platform-specific core services, the OSAL provides generic services that are implemented independently of the underlying OS: |
46 | | - |
47 | | -- **Priority Queue** — A heap-based priority queue implementation used by the framework for priority-aware message dispatch. |
48 | | - |
49 | | -### Implementation Architecture |
50 | | - |
51 | | -The OSAL uses a delegate pattern where each service has three layers: |
52 | | - |
53 | | -1. **Interface** — A pure-virtual base class defining the service contract |
54 | | -2. **Wrapper** — A final concrete class that application code interacts with, forwarding calls to the delegate |
55 | | -3. **Implementation** — A platform-specific class that implements the interface |
56 | | - |
57 | | -Services are accessed either as singletons (for global operations like file system queries and CPU statistics) or as handles (for stateful objects like individual files, mutexes, and tasks). The OSAL is initialized once at system startup, though singletons will self-initialize on first use if explicit initialization is omitted. |
58 | | - |
59 | | -### Error Handling |
60 | | - |
61 | | -All OSAL operations return typed status enumerations specific to each service. Platform backends translate native error codes into these status values so that application code never needs to interpret platform-specific errors. |
62 | | - |
63 | | -### Available Backends |
64 | | - |
65 | | -- **Posix** — Full implementation using POSIX APIs (pthreads, file I/O, clock_gettime). Default for Linux and macOS. |
66 | | -- **Stub** — No-op implementations that return NOT_SUPPORTED. Used as a starting point for platforms where some services are not yet implemented. |
67 | | -- **Community** — Additional backends for Zephyr RTOS, VxWorks, and FreeRTOS are maintained in the fprime-community GitHub organization. |
| 8 | +For instructions on porting the OSAL to a new platform, see [How-To: Implement an OSAL](https://github.com/nasa/fprime/blob/devel/docs/how-to/implement-osal.md). |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?v=4&size=40){kind=avatar}
0 commit comments