This preview shows pages 1–3. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.View Full Document
Unformatted text preview: A Tour of the Native API Purpose of this document This document is aimed at providing a general view of the native API which comes with Xenomai. Newcomers should find design information describing the logic behind this interface. This document should be a useful complement to the API reference manual. What is this API for? Since Xenomai is intrinsically API-agnostic, it can run various kinds of interface flavours, for instance VxWorks, pSOS+, uITRON or VRTX-like emulators, mimicking these traditional RTOS APIs, usually for porting legacy applications. But you may not necessarily want to build your brand new application over those emulators because compatibility with such interfaces is not an issue; in contrast, you may just want to use a programming interface which leverages all the capabilities of the underlying real-time core, and makes full use of its high integration level with the GNU/Linux environment. To this end, Xenomai brings two possibilities : a real-time extension of the standard POSIX API, and its own API of choice any application can use, which is semantically closer to the interfaces provided by traditional (non-POSIX) RTOS. The latter interface is simply called the native API, to differentiate from the others, which have been defined outside of the Xenomai realm. API characteristics Since Xenomai is about providing a stable and developer-friendly real-time system in a GNU/Linux environment, the native API follows these guidelines: A compact API The native API is reasonably compact, hopefully still providing a comfortable programming environment, in less than a hundred of distinct services. Orthogonality Care has been taken to avoid multiple variations of semantically and functionally close services, that would end up being only differentiated by varying names or details in their respective prototype. The rationale behind such design choice is plain simple: we feel that the level of freedom brought to the application developer by an API does not depend on the number of available system calls, but on the capacity she is given to identify, pick and combine the existing services in a non-ambiguous and reliable fashion. For this reason, those services must be orthogonal, always have a straightforward purpose, and rely on rock-solid basic Native API Tour RevC - 03/20/06 mechanisms independent from the general flavour or window-dressing exposed by the API....
View Full Document
- Spring '09