[CXP] Discussing the RTDM specification

Jan Kiszka jan.kiszka at siemens.com
Wed Dec 23 10:45:35 CET 2020


On 18.12.20 15:19, Philippe Gerum via Xenomai wrote:
> 
> This wiki page [1] contains a draft proposal about specifying which
> services from the current RTDM interface should be part of the Common
> Xenomai Platform. Some proposals for deprecation stand out:
> 
> - I suspect that only very few RTDM drivers are actually handling
>   requests from other kernel-based drivers in real world applications,
>   at least not enough to justify RTDM codifying these rare cases into a
>   common interface (rtdm_open, rtdm_read, rtdm_write etc).
> 
>   In other words, although I would agree that a few particular drivers
>   might want to export a couple of services to kernel-based clients in
>   order to provide them some sort of backchannel, it seems wrong to
>   require RTDM drivers to provide a kernel interface which would match
>   their user interface in the same terms. For these specific cases, ad
>   hoc code in these few drivers should be enough.
> 
>   Besides, I believe that most kernel->kernel request paths implemented
>   by in-tree RTDM drivers have never been tested for years, if ever.
>   Meanwhile, this kernel->kernel API introduces a basic exception case
>   into many RTDM and driver code paths, e.g. for differentiating kernel
>   vs user buffers, for only very few use cases.
> 
>   For these reasons, I would suggest to deprecate the kernel->kernel API
>   from RTDM starting from 3.3, excluding it from the CXP in the same
>   move.

That's fine with me. The idea was once that something like bus drivers
would appear, but that never happened.

> 
> - RTDM_EXECUTE_ATOMICALLY() and related calls relying on the Cobalt big
>   lock must go. For SMP scalability reasons, this big lock was
>   eliminated from the EVL core, which means that all the attached
>   semantics will not hold there. Serializing access to shared resources
>   should be guaranteed by resource-specific locking, not by a giant
>   traffic light like the big lock implements.

This is more complicated: RTDM_EXECUTE_ATOMICALLY was in fact deprecated
long ago, but users were migrated to cobalt_atomic_enter/leave which may
now make it look like we no longer need this. Maybe this is already the
case when using rtdm_waitqueue*, but let's convert everyone first.

> 
> - rtdm_mutex_timedlock() has dubious semantics. Hitting a timeout
>   condition on grabbing a mutex either means that:
> 

I think you are missing the use cases:

mutex-lock-timed
...
wait-event-timed
...
mutex-unlock
(which goes long with timeout sequences)

In fact, all that could be replaced with

mutex-lock
...
atomic-entry
mutex-unlock
wait-event-timed
mutex-lock
atomic-leave
...
mutex-lock

but that is what we want to replace as well...

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux



More information about the Xenomai mailing list