Page History

...

• Component Registration Management: Accepts and validates component capability registrations including namespace ownership, RBus/D-Bus endpoints, and version information against device profile configurations
• Namespace Discovery Service: Provides lookup services to discover which components support specific data model namespaces and dynamic table instances for inter-component parameter access
• Device Profile Loading: Parses and validates XML device profile configurations that define expected component topology, dependencies, and namespace allocations for the platform
• Data Type Validation: Verifies data model parameter types against registered namespace schemas to ensure type consistency across component boundaries
• System Readiness Coordination: Tracks component registration status and dependency fulfillment to determine overall system readiness state for upper-layer services
• Session Management: Manages registration sessions with priority handling and session ID allocation for transactional component registration operations
• Dual IPC Support: Supports both RBus and D-Bus messaging protocols through conditional compilation enabling flexible deployment configurations and migration strategies

Design

Component Registry implements a centralized registration and discovery architecture that serves as the authoritative source for component topology and namespace ownership information in the RDK-B middleware stack. The design prioritizes runtime flexibility, allowing components to dynamically register capabilities while maintaining schema validation against pre-configured device profiles. The architecture separates profile management from runtime registration tracking, enabling static validation rules while supporting dynamic component lifecycle management.

...

```mermaid
graph TB
    Config["XML Device Profile<br/>(cr-deviceprofile.xml)"] 

    ssp_main["ssp_main.c<br/>Initialization & Lifecycle"]
    ssp_ipc["ssp_rbus.c / ssp_dbus.c<br/>Message Bus Interface"]

    ProfileLoader["Profile Loader<br/>(ccsp_cr_profile.c)"]
    RegHandler["Registration Handler<br/>(ccsp_cr_operation.c)"]
    NamespaceMgr["Namespace Manager"]
    ComponentQueue["Component Registry Queue"]

    libxml2["libxml2"]
    libunpriv["libunpriv"]
    libtelemetry["libtelemetry"]
    rbus_dbus["RBus / D-Bus"]

    Config -->|load| ProfileLoader
    ProfileLoader -->|parse| libxml2
    ProfileLoader -->|populate| ComponentQueue

    ssp_main -->|init| ProfileLoader
    ssp_main -->|drop privs| libunpriv
    ssp_main -->|send events| libtelemetry
    ssp_main -->|launch| ssp_ipc

    ssp_ipc -->|register methods| rbus_dbus
    ssp_ipc -->|invoke| RegHandler
    ssp_ipc -->|publish events| rbus_dbus

    RegHandler -->|lookup| ComponentQueue
    RegHandler -->|register namespaces| NamespaceMgr
    RegHandler -->|check readiness| ComponentQueue

    NamespaceMgr -->|index| ComponentQueue

    rbus_dbus -->|component registration| RegHandler
    rbus_dbus -->|namespace discovery| RegHandler

    classDef config fill:#fce4ec,stroke:#c2185b,stroke-width:2px
    classDef ssp fill:#e3f2fd,stroke:#0277bd,stroke-width:2px
    classDef core fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
    classDef data fill:#fff3e0,stroke:#ef6c00,stroke-width:2px
    classDef external fill:#e8f5e8,stroke:#2e7d32,stroke-width:2px
    classDef bus fill:#e1f5fe,stroke:#01579b,stroke-width:2px

    class Config config
    class ssp_main,ssp_ipc ssp
    class ProfileLoader,RegHandler core
    class NamespaceMgr,ComponentQueue data
    class libxml2,libunpriv,libtelemetry external
    class rbus_dbus bus
```

Prerequisites and Dependencies

Build-Time Flags and Configuration:

...

• Threading Architecture: Multi-threaded with asynchronous message processing
• D-Bus variant: Uses CCSP message bus framework with internal threading via DslhCreateCpeController::Engage(); spawns waitingForSystemReadyTask as separate task
• RBus variant: Explicitly spawns threads for waiting on system ready (waitForSystemReady) and monitoring component dependencies (pollingComponentReady)
• Main Thread: Supervises component lifecycle and yields to IPC message processing threads
• Synchronization: Uses mutex locks (pthread_mutex_t) and condition variables (pthread_cond_t) for thread-safe access to component registry and system readiness state; synchronization mechanisms protect shared data structures during concurrent registration and discovery operations

Component State Flow

Initialization to Active State

...

• Device profile context switches between standard and Ethernet WAN profiles based on /nvram/ETHWAN_ENABLE file presence at startup
• IPC context varies between RBus and D-Bus processing depending on --with-rbus-build configuration

Call Flow

Initialization Call Flow:

...

```mermaid
sequenceDiagram
    participant Comp as CCSP Component
    participant IPC as RBus/D-Bus Layer
    participant CROper as CR Operations
    participant NS as Namespace Manager
    participant Queue as Component Queue

    Comp->>IPC: RegisterCapabilities(name, version, bus_path, namespaces[])
    IPC->>CROper: CcspCrRegisterCapabilities()
    CROper->>Queue: Lookup Component by Name
    Queue-->>CROper: Component Profile Info
    CROper->>CROper: Validate Version Match
    CROper->>NS: RegisterNamespaces(name, path, namespaces[])
    NS->>NS: Index Namespaces by Prefix
    NS->>NS: Store Component to Namespace Mapping
    NS-->>CROper: Registration Success
    CROper->>Queue: Mark Component Registered
    CROper->>CROper: Check System Readiness
    CROper-->>IPC: Return Status Code
    IPC-->>Comp: Registration Confirmed

    Note over Comp,Queue: Namespace Discovery Flow

    Comp->>IPC: DiscoverComponentSupportingNamespace("Device.WiFi.Radio.")
    IPC->>CROper: CcspCrDiscoverComponentSupportingNamespace()
    CROper->>NS: FindComponentByNamespace("Device.WiFi.Radio.")
    NS->>NS: Prefix Match Search
    NS-->>CROper: Component Name and Bus Path
    CROper-->>IPC: Component Info Array
    IPC-->>Comp: [Component Name, Bus Path, Subsystem]
```

Internal Modules

Component Registry is organized into distinct modules separating platform integration concerns, core registration logic, and data management responsibilities. Each module encapsulates specific functionality while maintaining clear interfaces for inter-module communication and data sharing.

Component Interactions

Component Registry serves as the central hub for all CCSP middleware interactions enabling component discovery and namespace resolution. CR interacts with every CCSP component during initialization registration and provides ongoing discovery services for inter-component communication routing.

Interaction Matrix

...

IPC Flow Patterns

Primary IPC Flow - Component Registration:

...

```mermaid
sequenceDiagram
    participant WebPA as WebPA Agent
    participant BusLayer as RBus
    participant CRRbus as CR RBus Handler
    participant CRMgr as CR Manager

    WebPA->>BusLayer: Subscribe("Device.CR.SystemReady")
    BusLayer->>CRRbus: Subscribe Handler
    CRRbus->>CRRbus: Add Subscriber to List
    CRRbus-->>BusLayer: Subscription Confirmed
    BusLayer-->>WebPA: Ack

    Note over CRMgr: Component Registrations Continue...

    CRMgr->>CRMgr: Last Expected Component Registered
    CRMgr->>CRMgr: Set isSystemReady = 1
    CRMgr->>CRRbus: Notify SystemReady Changed
    CRRbus->>BusLayer: rbusEvent_Publish("Device.CR.SystemReady", value=1)
    BusLayer->>WebPA: Event Notification (SystemReady = 1)

    Note over WebPA: WebPA proceeds with cloud connection establishment
```

Implementation Details

Major HAL APIs Integration

Component Registry does not directly integrate with HAL APIs. CR operates entirely within the RDK-B middleware layer and interacts with other CCSP components through message bus protocols. The component reads configuration files from the filesystem and uses standard Linux system calls for file I/O operations.

Key Implementation Logic

• Device Profile Selection: CR determines which device profile XML to load by checking for /nvram/ETHWAN_ENABLE file existence at startup; if present, loads cr-ethwan-deviceprofile.xml, otherwise loads cr-deviceprofile.xml

• Files: ccsp_cr_profile.c - CcspCrLoadDeviceProfile() function

• Component Version Validation: Registration requests validate component version against device profile expectations; mismatched versions result in registration rejection with CCSP_CR_ERR_UNKNOWN_COMPONENT error

• Files: ccsp_cr_operation.c - CcspCrRegisterCapabilities() version check logic

• Namespace Prefix Matching: Discovery operations use longest-prefix matching algorithm to find owning component for namespace queries

• Files: Namespace Manager from ccsp-common-library - invoked by CcspCrDiscoverComponentSupportingNamespace() in ccsp_cr_operation.c

• System Readiness Determination: CR tracks registered components against expected profile components; system is ready when all profile-defined components have successfully registered capabilities

• Files: ccsp_cr_base.c - CcspCrIsSystemReady() function checking component queue registration status

• IPC Protocol Abstraction: Build system conditionally compiles RBus or D-Bus interface layers based on --with-rbus-build configure option; core CR logic remains protocol-agnostic

• Files: Makefile.am - conditional compilation based on RBUS_BUILD_ONLY and RBUS_BUILD_INTEGRATED flags

• Error Handling Strategy: Registration failures log warnings but component operation continues; unknown component registrations are accepted and tracked in separate queue for diagnostic purposes

• Files: ccsp_cr_operation.c - registration validates against profile but does not reject unknown components

• Logging & Debugging: Both RBus and D-Bus variants use RDK Logger via RDK_LOG macros when DISABLE_RDK_LOGGER is not defined; falls back to rtLog functions when RDK Logger is disabled. Also uses CCSP trace macros (AnscTrace) for general trace output.

• Files: ssp_main.c, ssp_rbus.c, ssp_dbus.c; RDK Logger initialized in main via RDK_LOGGER_INIT() when FEATURE_SUPPORT_RDKLOG is defined

Key Configuration Files

Component Registry relies on XML device profile configurations that define expected component topology and namespace allocations for the platform.

...