On Thu, 2009-10-29 at 18:29 +0900, Didenko Sergey wrote: > Dear experts > > assuming I have: > > xenomai_tree - path to Xenomai source code > project_tree - path to my project (originally based on VxWorks) > > Which directories and files should I include to the project's makefile > to be able to compile and link it with Xenimai's VxWorks APIs instead > of VxWorks's API's? > Do I need only *.h and *.c files or any libraries are required? >
XENO_CONFIG := /usr/xenomai/bin/xeno-config CFLAGS:= $(shell $(XENO_CONFIG) --xeno-cflags) -g LDFLAGS:= $(shell $(XENO_CONFIG) --xeno-ldflags) -lvxworks This said, moving a pristine VxWorks application from a traditional RTOS environment to Linux requires some work, no API emulation layer will give you 1:1 mapping between the zillions of WRS APIs and Linux+Xenomai. Only playing whack-a-mole fixing syntactical/compilation issues until your app eventually builds and links is the fastest way to hell for such a porting exercise: this will NOT address the design-related issues that must exist (e.g. what will you do with your original I/O drivers, how and where will you put the kernel/user boundary when porting your code etc, etc). A core issue is that programming models are fundamentally different, i.e: - single-address space + flat/physically addressed memory + permanent supervisor privileges + sloppy device driver model VS - multiple process contexts + MMU protection + separate kernel/application address spaces + non-privileged CPU mode for applications + strict device driver model. And, while I'm at it, just in case you might have considered this: moving all of your original code to Linux kernel space on top of the Xenomai APIs there would be likely terribly wrong. Aside of the license issues (GPL vs proprietary), you may also have serious problems down the road porting your code. The Xenomai APIs _in kernel space_ are now deprecated, they were made available at a time when Xenomai had no user-space support, back in 2001. We have such support since 2004 and the in-kernel APIs were kept for backward compatibility purposes only, so moving a complex application today, to such an hostile environment for user-level code is basically masochistic. A safer way to this journey is: - assess which original I/O drivers have to be real-time and move them to kernel space on top of RTDM. - assess which original I/O drivers have direct Linux counter-parts, and/or does not have any RT requirement, and reuse/implement a regular Linux driver for those. - segregate what parts of your original code has to be RT enabled from the other more "relaxed" parts. - move the application code bulk to userland, on top of the Xenomai APIs there. Adapt the RT portions to the Xenomai APIs, use anything that fits for the rest (e.g. plain glibc). Driver-wise, there is rule #666 to abide by: in a dual kernel environment - like Xenomai 2.x - never, ever, plan to share an IRQ line between a real-time device and a regular one. As soon as anyone feels tempted by implementing such a construct, the design flaw is there, and something must have been wrongly assessed during the early porting steps. All in all, and to sum up: unless your application is 50 LOC at most, porting it to Linux will require some implementation re-design work, and Xenomai is no magic bullet to avoid that. What Xenomai aims at, is providing a _correct_ emulation of the core VxWorks services (~100 of them), which normally mitigates the impact of such re-design work. In other words, do not confuse Xenomai with running the actual, original RTOS within some virtual machine on top of a bare metal hypervisor. The hypervisor approach is not Linux at all, it is just enabling the legacy RTOS to run on the same hw than Linux. The former approach is about mimicking the original RTOS environment natively in a Linux context, which leads to very different trade-offs when porting. You may at the very least want to read that piece, not much yet, but this is still better than nothing: http://www.xenomai.org/index.php/Xenomai:Porting_From_RTOS > Sergey > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help -- Philippe. _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
