Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193 
was reviewed by Wayne Thornton

--
  
Wayne Thornton commented on a discussion on cpukit/include/rtems/dhrl.h: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150423

 > + * @brief Deterministic Hedged Read Library (DHRL) Public API
 > + *
 > + * @note This library is explicitly constrained to x86_64/amd64 
 > architectures.

Hi @gedare, thanks for the review.

You are correct, the current limitation is due to the inline assembly required 
for cache invalidation (clflush) and cycle timing (pause/rdtsc), which are 
currently hardcoded.

I agree that this shouldn't bottleneck the cpukit level. I will refactor the 
implementation to abstract those hardware-specific instructions behind 
architecture hooks in score/cpu/, keeping the core API clean.

However, I do want to flag a broader architectural concern. While the API will 
be portable, the actual efficacy of DHRL relies heavily on strict SMP core 
affinity and predictable memory controller behavior. On architectures with 
weakly ordered memory models or non-deterministic bus arbitration, a functional 
port might not be physically viable at the hardware level.

My plan is to define the hooks so that unsupported architectures can safely 
stub them out and return RTEMS_UNSATISFIED (or simply compile to a no-op 
fallback) to prevent unexpected hardware behavior on non-x86 targets. Thoughts?


-- 
View it on GitLab: 
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193
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

Reply via email to