[RFC] generic CAN/CAN FD susbsytem for RTEMS from scratch (LinCAN inspired)

[Gedare Bloom]

On Thu, Feb 29, 2024 at 6:40 AM Pavel Pisa <pisa at fel.cvut.cz> wrote:
>
> Hello Gedare
>
> On Tuesday 27 of February 2024 22:27:43 Gedare Bloom wrote:
> > On Mon, Feb 12, 2024 at 8:03 AM Pavel Pisa <pisa at fel.cvut.cz> wrote:
> > > Michal Lenc works on a new generic CAN/CAN FD subsystem for RTEMS under
> > > my supervision. The project has reached a phase where we will be very
> > > grateful for the review and pointing to required changes to start a
> > > discussion of possible inclusion into the RTEMS mainline. The project is
> > > currently being developed as a separate RTEMS application based on the
> > > OMK build
> > >
> > >  https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd
> > >
> > > But long-term intention is to move
> > >
> > >
> > > https://gitlab.fel.cvut.cz/otrees/rtems/rtems-canfd/-/tree/master/lib/can
> > >drv
> > >
> > > directory into RTEMS cpukit/dev/can directory and corresponding include
> > > files into cpukit/include/dev/can directory.
> >
> > Thanks. I will review this design and code, but it will be a few weeks
> > before I can do that. The directory location is a suitable choice.
>
> Thanks. I consider critical to discuse if queues access protection
> by rtems_interrupt_lock_acquire is appropriate etc. I.e., I see
> rtems_semaphore_obtain problematic because it would exhaust
> fixed configures resources easily. I am not sure, if there is
> rtems core / "kernel" equivalent to contained objects as are used
> for "userspace" pthread_mutex_lock etc... There are more such architectural
> questions where feedback from you, Joel, Sebastian and or Chis
> with deeper knowledge would help. This discussion should continue
> in public list or as issues setup for RTEMS CAN FD subsystem.
>

On a quick review, my recommendation would be to switch to using the
rtems_mutex mechanism of the self-contained objects, see
https://docs.rtems.org/branches/master/c-user/self_contained_objects.html

I believe this will be a more suitable solution than the more general
interrupt lock. It should be relatively straightforward to implement
this replacement for both the qends and the fifo structures. Each may
embed its own rtems_mutex. I see you already use a
rtems_mutex_recursive to protect the can_bus structure. I would avoid
a design that allows recursive access if possible. I did not see if
you acquire the lock during interrupt service routines.

Since you have the interrupt_lock mechanism implemented, may be it
would be a nice experiment to evaluate the performance vs the
self-contained rtems_mutex.

Gedare