RTDM open, open_rt, and open_nrt

[Per Oberg <pero@wolfram.com>]

Hello list

I am trying to understand how rtdm works, and possibly why out of a historical context. Perhaps there is a good place to read up on this stuff, then please let me know. 

It seems like in the rtdm-api there is only open, but no open_rt or open_nrt. 
More specifically we have: 
- read_rt  / read_nrt
- recvmsg_rt / recvmsg_nrt
- ioctl_rt / ioctl_nrt
- .. etc.

However, when studying an old xenomai2->3 ported driver it seems like there used to be open_rt and open_nrt. The problem I was having before (see my background comment below) was because the open had been mapped to the old open_nrt code, which in turned used a rt-lock, thus a mix of the two. When switching to a regular mutex it "worked", as in it didn't complain. 

In a short discussion Jan Kiszka gave me the impression that open could possibly end up being rt or nrt depending on situation. 

PÖ: I'm guessing that open is always non-rt and therefore a rtdm_lock should be used? ...

JK: This depends. If the open code needs to synchronize only with other non-RT
JK: paths, normal Linux locks are fine. If there is the need to sync with the
JK: interrupt handler or some of the _rt callbacks, rtdm_lock & Co. is needed.


So, how does this work? And why was (if it was) open_nrt and open_rt replaced with a common open?


Background
----------------
I recently wrote about a driver which warned about "drvlib.c:1349 rtdm_mutex_timedlock". I got good answers which led me to some more general questions, but instead of continuing in the old tread I thought it better to start a new one since it's not about the initial problem. The driver in case is the Peak Linux Driver for their CAN hardware, see [1]


[1] https://www.peak-system.com/fileadmin/media/linux/index.htm


Best regards
Per Öberg