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