Re: RTDM open, open_rt, and open_nrt

[Per Oberg <pero@wolfram.com>]

----- Den 16 sep 2019, på kl 11:34, Jan Kiszka jan.kiszka@siemens.com skrev: 

> On 16.09.19 09:32, Per Oberg via Xenomai wrote: 
> > 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? 


> The original RTDM design was foreseeing the use case of creating and destroying 
> resources like file descriptors for devices in RT context. That idea was dropped 
> as also the trend for the core was clearly making this less realistic. 
> Therefore, we removed open/socket_rt from Xenomai 3. 

> If you have a driver that exploited open_rt, you need to remove all rt-sleeping 
> operations from its open function. If rtdm_lock is an appropriate alternative 
> depends on the driver locking structure and the code run under the lock. 
> rtdm_lock_get makes the lock holder unpreemptible. So, if rtdm_mutex was chosen 
> because of lengthy code under the lock, that would not be a good alternative. 
> Then we would have to discuss what exactly is run there, and why. 

Ok, can I read up on this somewhere? I found [1], is that still valid in this context? ( Oh, and can we expect a third edition perhaps ? =) ) 

[1] Building Embedded Linux Systems: Concepts, Techniques, Tricks, and Traps 2nd Edition, Kindle Edition 

> > 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 


> Did you inform them about their problem already? Maybe they are willing to fix 
> it. We can't, it's not upstream code. 

No, I haven't, but I will. The reason I haven't yet is because I was under the impression that this didn't happen to them. I'm trying to compile everything (driver, lib, and application) in a Yocto based SDK setup and it seems like compilation flags and environment variables are getting squashed in interesting ways. My reasoning so far was that I got this wrong somehow. 

Then there's the fact that making it work is only part of the goal. I do really want to understand how this fits together. 

> Jan 



> -- 
> Siemens AG, Corporate Technology, CT RDA IOT SES-DE 
> Corporate Competence Center Embedded Linux 

Thanks 
Per Öberg