Dear Philippe Thank you very much for the detailed explanation. That was exactly what I need to understand once again and again. Yes, I have read the "Porting_From_RTOS", but my next small step is just to reuse APIs provided by Xenomai.
*may I test my understanding in one thing "where Xenomai should be installed?"* I have my Linux based PC with: $linux_tree = /home/d.sergey/kernel/linux-2.6.29-v02.00.29 (patched with xenomai + added support for MV 88F6290 Platfrom) $xenomai_root = /home/d.sergey/xemomai/xenomai-2.4.9.1 $build_root = /home/d.sergey/build_root $staging_dir = /nfs/rootfs after patching linux_tree with Xenomai and Adeos... I have done: ====================== cd $linux_tree make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root project_defconfig -j5 make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- O=$build_root bzImage modules -j5 ====================== then ====================== cd $build_root /home/d.sergey/xemomai/xenomai-2.4.9.1/configure --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi --enable-arm-mach=generic --enable-arm-tsc make DESTDIR=/nfs/rootfs install ====================== *Gilles, is that what you said ?* > You need to install Xenomai, running 'make install' in the build tree. > *Or should I install Xenomai on my Linux based PC?* (Right now I assume it is installed on my target's rootfs) > Then use xeno-config. > *Sorry, but I did not get how should I use it? Please give me more details!* *I also do not understand for what the $build_root folder is required? Why can not **we **compile the Xenomai's code it its tree?* Philippe, I understand all the things you have mentioned... > 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. > But, for the next step of my journey*, *I simply need to emulate the API layer, that is it!* Please help me to understand how can I emulate the APIs. Right now I just need to make my code be able to use Xenomai's APIs. *I'm not saying that right after that I will try to run my project on the target and will complain why it is not working, no... Just to do next step, I want to make my code compile and link with new APIs. Looking forward to hearing from you. * *Sergey 2009/10/29 Philippe Gerum <[email protected]> > 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
