[CXP][RFC] Pick RTDM for the common kernel interface
rpm at xenomai.org
Mon Dec 14 18:13:59 CET 2020
Greg Gallagher <greg at embeddedgreg.com> writes:
> On Mon, Dec 14, 2020 at 7:45 AM Jan Kiszka via Xenomai <xenomai at xenomai.org>
>> On 06.12.20 17:56, Philippe Gerum via Xenomai wrote:
>> > The common Xenomai platform specification is about defining the
>> > commonalities among future Xenomai releases starting from 3.3,
>> > including the Xenomai 4 series based on a next generation (EVL)
>> > core. A common kernel interface available for implementing
>> > Xenomai-controlled drivers is part of this specification.
>> > Xenomai 3.x and earlier have long promoted the RTDM interface for
>> > implementing drivers, which encourages a separated driver model by
>> > design. Instead, the EVL core which is going to be the cornerstone of
>> > Xenomai 4 promotes an integrated approach to developing real-time
>> > drivers when possible, by adding so-called "out of band" capabilities
>> > directly to the implementation of existing mainline drivers . A
>> > custom EVL driver which has no counterpart in the mainline kernel tree
>> > is still a regular character device driver, although it must use the
>> > real-time services brought by the EVL core for its time-critical
>> > operations .
>> > The purpose of defining a common kernel interface as part of the CXP is
>> > specifically about helping with portability of existing custom drivers
>> > built for Xenomai 3.x towards Xenomai 4. Following the regular driver
>> > model as promoted by EVL along with using the EVL core interface
>> > directly would be the recommended way of developing drivers for Xenomai
>> > 4.
>> > However, some RTDM features/services cannot be ported to an EVL-based
>> > system, due to major differences between the Cobalt and EVL locking
>> > models (e.g. RTDM_EXECUTE_ATOMICALLY(), along with any call involving
>> > Cobalt's single "superlock").
>> > PROPOSAL: Adopt a large subset of the current RTDM specification as
>> > the common kernel interface defined by the CXP. The exact set of RTDM
>> > services which should be retained in the CXP implementation must be
>> > discussed further.
>> > As a consequence, Xenomai 4 would provide a RTDM layer based on the EVL
>> > core interface internally, which would preserve the driver taxonomy
>> > ("named" / "protocol") and registration model inherited from its Xenomai
>> > 3.x counterpart.
>> > drivers
>> > ....................................
>> > | | |
>> > | | |
>> > RTDM RTDM |
>> > | | |
>> > v v v
>> > (Cobalt core xn* API) (EVL core evl_* API)
>> > --------------------- --------------------
>> > Xenomai 3.x Xenomai 4
>> > Applications could issue I/O requests to RTDM-based drivers via the
>> > dedicated services from the common libcobalt interface also available
>> > in both environments .
>> > Thanks,
>> >  https://evlproject.org/core/oob-drivers/
>> >  https://evlproject.org/core/oob-drivers/gpio/
>> >  https://evlproject.org/core/kernel-api/
>> >  https://xenomai.org/pipermail/xenomai/2020-December/043930.html
>> Ack regarding the commitment to RTDM compat support. How that RTDM
>> version will eventually look like is not yet clear to me, though. It may
>> not be 1:1 what we have today.
>> E.g., both EVL and RTDM have to provide separate (from the kernel)
>> synchronization primitives. I would see a lot of benefit in aligning
>> them, rather than having yet another new set with EVL. People should be
>> able to do
>> #define rtdm_mutex_lock evl_lock_kmutex
>> or vice versa.
> The compatibility with RTDM I think makes a lot of sense. I think the goal
> should be if someone as a current RTDM driver there would be minimal change
> to move it to a new version of Xenomai 3.x or 4. As we start on this work
> it may be a great time for people to get involved and help maintain some of
> the existing drivers.
To me, RTDM over EVL should be mostly composed of a set of simple if not
trivial wrappers to EVL core services, just like RTDM for Xenomai 2.x,
3.x has been wrapping rtdm_* calls to xn* services. Taking Jan's
example, there would be no issue in doing this on the EVL side:
typedef struct evl_kmutex rtdm_mutex_t;
int rtdm_mutex_lock(rtdm_mutex_t *mutex)
This could be done for most RTDM services we have today. Not
surprisingly, since the EVL core is originally a fork of Cobalt, the
semantics are very close if not identical for most features.
A couple of EVL-specific additions (e.g. stax lock) are not represented
in the RTDM API, but this should not be a issue: RTDM over Xenomai 4/EVL
would only exist for the purpose of building Xenomai 3.x drivers over
Xenomai 4 with no change for the most part. In that sense, I'm on the
same page as Wolfgang.
I'll come up with a series of possible mappings from RTDM to EVL
services, to discuss such wrapping further.
More information about the Xenomai