Repository navigation
hal: hal_strerror() texts for -EALREADY/-EBUSY; rtapi_delay() doc - #4681
Conversation
grandixximo
left a comment
grandixximo
left a comment
There was a problem hiding this comment.
The paragraph next to the new text still says the max delay is "usually approximately 1/4 of the clock period", in both the man page and rtapi.h. Only RTAI kernel modules compute it that way (timer_period / 4). rtapi_delay_max() returns a fixed 10000 ns in uspace realtime modules and 999999999 ns in user processes. Since this PR already rewrites the description, could you fix that sentence too? Either give the per-platform values, or say the max is implementation dependent and callers should check rtapi_delay_max().
|
@grandixximo Done in 1a8f7b2: the man page now says the value is implementation dependent and gives it per platform — 1/4 of the clock period in RTAI kernel modules (10 µs until the clock is set), 10 µs in uspace realtime modules, just under one second in user processes. rtapi.h never carried the 1/4 wording, but I added the same note to rtapi_delay_max() there so both places agree. |
|
Thanks, the per-platform values look right. #4461 just moved |
hal_init_funct_to_thread() and hal_del_init_funct_from_thread() return -EALREADY once the init cycle has run, and funct_entry_release() returns -EBUSY when a function is removed from a running thread in RTAPI. Callers that report errors through hal_strerror() got "unknown error" for both. Signed-off-by: yurc <yurik.x@gmail.com>
The message used strerror() because hal_strerror() had no text for
-EALREADY ("Operation already in progress" for an init cycle that has
already run).
Signed-off-by: yurc <yurik.x@gmail.com>
rtapi.h and rtapi_delay(3) say it simply loops, wasting CPU cycles, and rtapi.h says user processes may not call it. Only RTAI kernel modules busy-wait (rt_busy_sleep()). uspace realtime modules sleep through the backend (clock_nanosleep() on POSIX and Xenomai, evl_sleep_until() on EVL, rt_sleep() on RTAI), and user processes have rtapi_delay() too and sleep with clock_nanosleep() (hal_lib uses it in ULAPI). Signed-off-by: yurc <yurik.x@gmail.com>
Except in RTAI kernel modules rtapi_delay() sleeps, so a realtime task may wake up considerably later than requested and lose its timing. Keep init/cleanup code as the supported use. Signed-off-by: yurc <yurik.x@gmail.com>
1/4 of the clock period holds only for RTAI kernel modules (rtai_rtapi.c). uspace realtime modules return a fixed 10000 ns (uspace_rtapi_main.cc), user processes 999999999 ns (uspace_ulapi.c, rtai_ulapi.c). Signed-off-by: yurc <yurik.x@gmail.com>
|
@grandixximo Rebased onto current master; the rtapi.h hunks followed the move to include/rtapi.h unchanged. |
1a8f7b2 to
b26462f
Compare
3 participants
Follow-up to #4630.
hal_strerror()had no text for-EALREADY(init cycle already run) or-EBUSY(function removed from a running thread in RTAPI), so the halcmdunloadrtinit-entry error usedstrerror(); it now useshal_strerror().rtapi.handrtapi_delay(3)saidrtapi_delay()loops and that user processes may not call it. Only RTAI kernel modules busy-wait; uspace sleeps in the backend (clock_nanosleep(),evl_sleep_until(),rt_sleep()) and ULAPI withclock_nanosleep().Tested: uspace run-in-place build with
--enable-werror;runtests tests/hal-* tests/halcompile tests/halrun-*17/17; the new texts checked viahal_strerror()from liblinuxcnchal.