Wayne Thornton commented on a discussion on cpukit/dhrl/dhrl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150683 > + dhrl_worker_loop, > + (rtems_task_argument) ctx > + ); > + rtems_task_start( > + ctx->worker_b_id, > + dhrl_worker_loop, > + (rtems_task_argument) ctx > + ); > + > + dhrl_calibrate_interleave( ctx ); > + > + return RTEMS_SUCCESSFUL; > +} > + > +/* Execution */ > +rtems_status_code dhrl_run_loop( void ) I originally considered spawning a third task internally for the main run loop, but I decided to stick with the "caller provides the thread" pattern. I want the application developer to have complete control over the driver thread's attributes such as stack size, priority, CPU affinity without us having to bloat `dhrl_config` to pass those parameters down. It also keeps our `confdefs` memory footprint strictly limited to the two bare-metal worker tasks. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150683 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
