MITHILESH MATTAPALLI commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_142829 I have been analyzing this issue scope for my **GSoC 2026** proposal. Following up on the queue initialization race conditions I investigated in **!1059**, I wanted to share my findings on the current state of the stack and validate my proposed architecture. **Observations from Code Study:** 1. **Testing Gap:** The current regression testing relies heavily on physical hardware, which limits our ability to catch race conditions in CI. 2. **Controller Support:** As @ppisa noted, QEMU has mainline support for **SJA1000** and **CTU CAN FD**, but these are primarily exposed as PCI devices. The RTEMS Tester currently lacks a standard BSP configuration to utilize these for automated testing. 3. **Core Fragility:** The `can_queue_create` path lacks robust error handling for kernel object creation failures, leaving the stack in an undefined state during initialization faults. **Understanding & Proposed Plan:** My proposal will focus on **'Hardening & Virtualization'** to address both the "New Controller" and "Rigorous Test Suite" requirements: * **Virtual Lab (The "Rigorous Test Suite"):** I will integrate the **CTU CAN FD** PCI support into the RTEMS Tester. This involves configuring a generic BSP (likely `pc386` or `pc686`) to enumerate the QEMU PCI bus and load the driver, enabling a purely software-based regression suite. * **Core Hardening:** I will refactor the `can-queue` layer to enforce atomic state transitions, ensuring that resources are cleanly rolled back if initialization fails (addressing the root cause of !1059). **Question for Mentors (@ppisa):** Regarding the QEMU integration, would you prefer the test suite target a generic PCI-capable BSP (like `pc386`) to leverage the existing QEMU PCI support, or should we aim to extend a specific embedded BSP (like `xilinx_zynq`) to support these virtual controllers? My assumption is that the generic PCI approach is more stable for CI purposes. I am drafting the detailed proposal based on this architecture. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5440#note_142829 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
