rtapi_print(3rtapi)

πŸ“¦
version 2.9.4 Β· 2 versions
, in debian trixie, ubuntu questing, ubuntu resolute, ubuntu stonking

πŸ’– rtapi_print β€” bestie's guide to yelling into the void (politely)

okay so this is a 3rtapi manual page, and it's about the two lil functions that let you print diagnostic messages β€” rtapi_print and rtapi_print_msg. that's the whole vibe. no cap. 🫢


✨ NAME ✨

rtapi_print, rtapi_print_msg β€” print diagnostic messages


πŸŽ€ SYNTAX πŸŽ€

like, here's the exact shape of everything, copy it character for character bestie:

void rtapi_print(const char *fmt, ...)

void rtapi_print_msg(int level, const char *fmt, ...)

typedef void(*rtapi_msg_handler_t)(msg_level_t level, const char *msg);

void rtapi_set_msg_handler(rtapi_msg_handler_t handler);

rtapi_msg_handler_t rtapi_get_msg_handler(void);

πŸ¦‹ ARGUMENTS πŸ¦‹

  • level β€” a message level, and it has to be one of RTAPI_MSG_ERR, RTAPI_MSG_WARN, RTAPI_MSG_INFO, or RTAPI_MSG_DBG. those are the options, pick one πŸ’…
  • handler β€” a function that gets called from rtapi_print or rtapi_print_msg to, like, actually output the message. it's the thing that does the printing fr fr.
  • fmt, ... β€” the other arguments are exactly as for rtapi_vsnprintf(3rtapi). same energy, same rules.

🌸 DESCRIPTION 🌸

so rtapi_print and rtapi_print_msg work like the standard C printf functions… except a reduced set of formatting operations is supported. that's the catch, bestie, it's giving "printf but she went to a smaller school."

notably:

  • formatting long-long values? not supported. πŸ’€
  • formatting floating-point values? has different behavior than standard printf. so do not come in here expecting printf behavior, okay? adjust your expectations, queen.

depending on the RTOS, the default may be to print the message to stdout, stderr, a kernel log, etc. so where it lands is lowkey a mystery until you know your RTOS. in RTAPI code, the action may be changed by a call to rtapi_set_msg_handler. a NULL argument to rtapi_set_msg_handler restores the default handler. rtapi_msg_get_handler returns the current handler. and when the message came from rtapi_print, level is RTAPI_MSG_ALL.

rtapi_print_msg works like rtapi_print but it only prints if level is less than or equal to the current message level. so it's the picky one. it has standards. iconic honestly.


πŸ‘‘ REALTIME CONSIDERATIONS πŸ‘‘

okay this part matters, pay attention bestie, this is the "can I call this where" section:

  • rtapi_print and rtapi_print_msg may be called from non-realtime, init/cleanup, and realtime code. slay, they're flexible.
  • rtapi_get_msg_handler and rtapi_set_msg_handler may be called from realtime init/cleanup code.
  • a message handler passed to rtapi_set_msg_handler may only call functions that can be called from realtime code.
⚠️ that last one is not a suggestion, it's a rule. if your handler calls something realtime-forbidden, that's on you and it will not be cute. πŸ™ˆ

⭐ RETURN VALUE ⭐

None. nothing. nada. these functions return void, they're not here to give you answers, they're here to give you messages. periodt. πŸ’œ


🌈 SEE ALSO 🌈


and that's the whole page, bestie!! πŸŽ€ this one's from the LinuxCNC Documentation, dated 2006-10-12, and it's the rtapi_print(3rtapi) manual. go forth and print your diagnostics, you absolute main character πŸ¦‹βœ¨