Re: [CXP][RFC] pick POSIX/cobalt for the common user API

[Philippe Gerum <rpm@xenomai.org>]

Hi,

chensong via Xenomai <xenomai@xenomai.org> writes:

> hi Philippe,
>
> As far as i know, some vxworks customers like xenomai because they can
> move their RT processes from vxworks to linux without rewriting their 
> code by the help of vxworks skin.
>
> If we "Excluding the legacy RTOS emulators such as VxWorks", we will
> lose them. It could depend on the balance of the request and effort.
>

There are two different aspects to consider. First, there is the CXP
which should define a common ground between future Xenomai releases
starting from 3.3, which is different from deciding on the feature set
such releases would include in total eventually. We may want a given
Xenomai release to support multiple APIs, which would definitely include
the one specified by the CXP.

In that sense, I'm only excluding the VxWorks API as a possible choice
for the common API specified by the CXP since this would have no upside
with respect to usability or portability from Xenomai 3.x to 4.x. I was
not referring to the presence of the VxWorks API in future Xenomai 3.x
releases, although the complete lack of feedback from users regarding
the RTOS emulators may simply mean that most projects already moved away
from these legacy APIs anyway.

Next, there is the question of whether the VxWorks API, and generally
speaking RTOS emulators should be present in Xenomai 4. I'm going to
oppose to such inclusion. These are my reasons:

- as I just hinted at, I believe that too few projects might still be
  interested in moving from VxWorks to Linux based on API emulation
  these days, at least not enough to justify the cost of maintaining
  RTOS emulators. I reckon that most of the legacy apps which should
  move to Linux already did so by now, many of them based on API
  conversion instead (e.g. VxWorks -> POSIX). We need to keep in mind
  that those emulators only cover the BSP-independent APIs, those which
  can be easily converted to another dialect because there is no
  hardware-related specifics, with their underlying semantics being very
  similar (e.g. VxWorks mutex-typed sema4s and POSIX mutexes are quite
  close in essence).

- generally speaking, Xenomai 4 is going to be all about simplicity and
  resource-efficiency, in order to address use cases, which I believe
  are beyond native preemption's reach: meeting ultra-low latency
  requirements reliably without having to play whack-a-mole with tricky
  runtime settings, regardless of the ongoing system stress, down to
  low-end hardware. We should be heading for a real-time sub-system
  which just delivers out of the box once enabled in the kernel, nicely
  integrated into the Linux environment, not on the edge of it. Basic
  but usable, simple but efficient. Among other things, this should
  involve a limited set of dedicated APIs, all with native support from
  the real-time core, which is to say without requiring any mediating
  layer like libcopperplate. As a matter of fact, libcopperplate was
  designed as a set of common blocks for implementing non-native APIs
  like RTOS emulators on top of a native interface.

- the Xenomai project has always run on a very limited amount of human
  resources, including for implementing and more importantly maintaining
  APIs. Each additional API is one burden more for Xenomai contributors
  to maintain, and users to comprehend.  I'd rather make sure that a
  single API is shared and exercised by many users, properly maintained
  and documented, compared to having many - potentially unused - APIs
  diluting the maintenance effort.

-- 
Philippe.