RTEMS | Draft: cpukit: add support for common CAN/CAN FD stack (!49)

[Pavel Pisa (@ppisa)]

Pavel Pisa commented on a discussion on cpukit/include/dev/can/can.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108445

 > +/** @} */
 > +
 > +/**
 > + * @brief This structure represents parameters of FIFO queue. It is used to
 > + *  setup new queues via @ref RTEMS_CAN_CREATE_QUEUE ioctl call.
 > + */
 > +struct can_queue_param {
 > +  /**
 > +   * @brief This member specifies queue's direction. Use @ref RTEMS_CAN_QUEUE_RX
 > +   *  or @ref RTEMS_CAN_QUEUE_TX
 > +   */
 > +  uint8_t direction;
 > +  /**
 > +   * @brief This member specifies queue's priority. Maximum priority value
 > +   *  is available from @ref RTEMS_CAN_QUEUE_PRIO_NR define. Higher number
 > +   *  means higher priority.

The code can reverse assignments but I would have some preference for keeping higher numeric value to be higher priority.
- it is more natural for compare
- POSIX keeps that notation [pthread_setschedprio](https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setschedprio.html)
- the applications and services which do not set the priority or use zero should be low priority by default to not cause link level priority inversion for high priority classes by uncontrolled sending of low priority CAN ID message (yes in this case high numeric value)

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/49#note_108445
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240628/e1166cf5/attachment-0001.htm>