clear to me, many thanks.
BR
chensong
On 2020年12月07日 18:12, Philippe Gerum wrote:
Hi,
chensong via Xenomai <[email protected]> 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.
