docs: Add daemon architecture documentation#331
Conversation
|
NB: This was generated by Claude Sonnet 4.5 and lightly edited. |
| - DSP cannot call back to system services on APPS (no reverse RPC for system services) | ||
| - DSP cannot request additional memory from APPS heap (audio PD limitation) | ||
| - DSP cannot access files on the APPS filesystem | ||
| - FARF log messages from DSP code are lost |
There was a problem hiding this comment.
Last 4 points are specific to root PD and static PD(audio, sensors) of DSP.
Any dynamic pd will still be able to do all these things using the corresponding APPS process.
|
|
||
| ## Overview | ||
|
|
||
| FastRPC daemons (`adsprpcd`, `cdsprpcd`, `sdsprpcd`, `gdsprpcd`) are optional system services that enhance FastRPC functionality. Each daemon corresponds to a specific DSP type (ADSP, CDSP, SDSP, GDSP) available on the SoC. |
There was a problem hiding this comment.
Daemons run on the CPU side (HLOS) and act as the “default listener” for the DSP static PDs(root PD, audio PD, sensors PD), handling reverse-RPC requests that require file-system, memory requests or privileged services the DSP cannot perform itself.
| - `adspmsgd` - DSP message logging interface | ||
| - `apps_std` - File I/O operations (fopen, fread, fwrite, etc.) | ||
| - `apps_mem` - Dynamic memory allocation from APPS | ||
| 3. **Forwards DSP logs**: Receives FARF messages from DSP and writes them to syslog/dmesg |
There was a problem hiding this comment.
all above points are mostly in context of root or static PDs.
|
|
||
| ### rootpd (Default) | ||
| - **Usage**: `cdsprpcd` or `cdsprpcd rootpd cdsp` | ||
| - **Provides**: |
There was a problem hiding this comment.
Copying few details from my doc for PD specific daemons:
Root PD (Guest OS) - adsprpcd, cdsprpcd
-
Purpose:
- Attaches to the DSP Root PD (Guest OS) and acts as the default listener for reverse-RPC.
- Provides file operations and dynamic-loading support used by components that run in Root PD (e.g., preload features, shell not accessible by user process).
- Helps create/maintain Root PD process context; from a user standpoint, you don’t call it directly, FastRPC does.
-
If adsprpcd isn’t running:
- Root PD features that rely on file I/O or dynamic loading from HLOS can fail (preloads may not work, RootPD-side reverse-RPC requests will time out).
- Audio PD dynamic loading may still work if audio-adsprpcd is up, but any RootPD-driven fastRPC services would be impacted.
Audio PD - adsprpcd with audiopd argument
-
Purpose:
- Attaches to the Audio static PD and serves reverse-RPC for audio PD.
- Performs dynamic loading of audio shared objects (.so) and reads calibration/config files (e.g., ACDB) on behalf of audio PD.
- Handles remote heap growth / CMA donation flows needed by audio (kernel fastRPC driver may do qcom_scm_assign on buffers; the daemon coordinates the user-space side).
-
If audioadsprpcd isn’t running:
- Audio dynamic module loading fails (dlopen/dlsym won’t resolve).
- Calibration/config file accesses fail, and audio features/algorithms that depend on dynamically loaded code won’t start.
There was a problem hiding this comment.
Thanks a lot for sharing all of these remarks! I've integrated them in an updated version
|
Seeing that this is receiving some nice review, I'm going to ambitiously mark this as Ready for review and remove the Draft flag :) |
|
I've fixed/clarified the number of sessions being 4 and being per process, as this was a key concern with the daemon presence. |
| - **1 FastRPC session slot** - Each daemon holds one persistent session | ||
| open to the DSP. The user-space library enforces a per-process limit | ||
| (`NUM_SESSIONS`, default 4 in `inc/fastrpc_common.h`). Since the | ||
| daemon runs as a separate process, it uses 1 of its own 4-session |
There was a problem hiding this comment.
cc @Srinivas-Kandagatla . I was under the impression that daemon would also consume some 'global' resources/sessions, which does not seem to be the case reading this paragraph.
Hi all, is this ready for merging? |
| sensors PD). Note that dynamic PDs can still perform these operations | ||
| using their corresponding APPS (Application Processor Subsystem) process. | ||
|
|
||
| - DSP static PD exceptions and crashes are silent - no error messages |
There was a problem hiding this comment.
When a dynamic user PD running on the DSP crashes, its exception handler sends all crash-related information to the root PD on the DSP before termination. The root PD then forwards this information to the root PD daemon, which logs it in the system log (syslog).
Logging user PD exception details to syslog is supported only for dynamic user PDs by the corresponding root daemon for the DSP (for example, adsprpcd for aDSP and cdsprpcd for CDSP). This feature is not available for static PDs.
By default, a crash in a static PD results in a DSP crash. On systems that support PDR for static PDs, the static PD is restarted instead.
|
|
||
| **What works with daemons enabled:** | ||
| - All basic FastRPC operations (same as without daemon) | ||
| - Static PD exception messages forwarded to system logs - critical for |
There was a problem hiding this comment.
exception logging is only supported for dynamic PDs by root PD daemons
| - **CPU usage**: Event-driven, blocks waiting for DSP callbacks. Negligible CPU consumption except when processing DSP exceptions or log messages. | ||
|
|
||
| **When to run:** | ||
| - **Development/debugging**: Always recommended - static PD errors otherwise disappear silently |
There was a problem hiding this comment.
Dynamic PD exception log disappears if root PD daemon is not run for that DSP.
|
|
||
| **When to run:** | ||
| - **Development/debugging**: Always recommended - static PD errors otherwise disappear silently | ||
| - **Production**: Recommended if static PD exception visibility is needed |
There was a problem hiding this comment.
Recommended to run root PD daemon if dynamic PD exception visibility is needed
| - **Development/debugging**: Always recommended - static PD errors otherwise disappear silently | ||
| - **Production**: Recommended if static PD exception visibility is needed | ||
| - **Resource-constrained**: Can safely omit if not using that DSP and logs aren't critical | ||
| - **Note**: Omitting the daemon doesn't break application functionality, only static PD observability |
There was a problem hiding this comment.
please rephrase to "Omitting the root PD daemon does not break application functionality, only dynamic PD exception visibility".
Static PD daemons are still needed if dynamic loading/file operations support is required.
| - Attaches to the DSP Root PD (Guest OS - typically QuRT, the Qualcomm | ||
| Real-Time OS running on the DSP) and acts as the default listener for | ||
| reverse-RPC | ||
| - Provides file operations and dynamic-loading support used by components that |
There was a problem hiding this comment.
dlopen() is not supported on the root PD on the DSP due to security constraints; only file operations are permitted for components running in the root PD. Most of these use cases are internal to the FastRPC framework. please remove "dynamic loading support"
The primary client-facing use case from the root PD daemon is routing dynamic PD exception logs to syslog. Other use cases involve internal functionalities required by the FastRPC framework operating within the root PD on the DSP.
| - **Services provided**: | ||
| - Exception logging via `adspmsgd` framework (see [adspmsgd.md](adspmsgd.md)) | ||
| - Remote file system access via `apps_std` interface | ||
| - Dynamic loading support (dlopen/dlsym/dlclose) |
There was a problem hiding this comment.
Dynamic loading (dlopen) is not supported on root PD running on the DSP. this point can be removed.
Dynamic loading (dlopen) is supported only on user PDs (static PD/dynamic PD).
Document the role of FastRPC daemons (adsprpcd, cdsprpcd, etc.) and clarify when they are needed. Explains that FastRPC works in two modes: - Basic mode (without daemons): All RPC calls work, but static PD exceptions are silent and static PDs cannot access system services on APPS (dynamic PDs are unaffected) - Full-featured mode (with daemons): Adds exception logging, reverse RPC for file I/O and memory allocation, lifecycle management (SSR/PDR) Clarifies the distinction between static PDs (root PD, audio PD, sensors PD) which need daemons for system services, and dynamic PDs which communicate directly with their APPS process. Includes resource usage details with references to specific constants in the source code (ADSP_LISTENER_MEM_CACHE_SIZE, DEFAULT_MEMORY_SIZE), and defines technical terms (PDs, HLOS/Linux, APPS, FARF, QuRT, ACDB). Closes: qualcomm#321 Signed-off-by: Loïc Minier <loic.minier@oss.qualcomm.com>
Add Container Considerations section documenting filesystem namespace implications for static vs dynamic PD workloads in containerized environments. Most ML/compute workloads (dynamic PDs) work fine; audio workloads (static PDs) need host filesystem coordination. Signed-off-by: Loïc Minier <loic.minier@oss.qualcomm.com>
|
@Chennak-quic thanks for the thorough review! I've pushed incremental fixup commits to address your feedback, pushed, then squashed them back to two commits and pushed again; hopefully this will make my latest changes easy for you to review. Would you mind taking another look? |
Hmm somehow github is hiding the intermediate push, but you can see the commits here: |
4 participants
Document the role of FastRPC daemons (adsprpcd, cdsprpcd, etc.) and
clarify when they are needed. Explains that FastRPC works in two modes:
are silent and DSP cannot access system services on APPS
file I/O, and memory allocation services
Closes: #321