On 08/05/2004 11:28 AM Philippe Gerum wrote: > On Thu, 2004-08-05 at 10:38, Wolfgang Grandegger wrote: >> Hi Philippe, >> >> I'm currently looking into Xenomai, Fusion, Skins and friends and this >> raised a few questions especially concerning usability: >> >> - How usable is this technologie already today, for example, if I want >> to port a PSOS or VxWorks application to Linux/Xenomai using the >> corresponding skin. How complete, mature and stable is such a "skin". >> Is there any experience with real projects. >> > > o Completeness > > As a foreword, all skins have been crafted in order to expose the core > API of the target RTOS; this means that you should not miss any > arch-independent fundamental service, but the hi-level libraries are not > emulated (e.g. VxWorks's taskLib, msgQLib, sem*Lib... ok, but no ansi*, > usrLib, dhcpLib and so on) . > The missing arch-dependent stuff (i.e. BSP-level) is expected to be > implemented during the porting effort using ad-hoc code, because it's > impossible to generalize it at Xenomai's level anyway. > > - The pSOS+ core is quite exhaustively emulated with 56 calls. > - VxWorks emulates more than 50 calls too: intLib and portions of > intArchLib, kernelLib, msgQLib, sem[BCM]Lib, sysLib, taskLib, > taskHookLib, taskInfoLib, tickLib and wdLib. > - VRTX is simple and complete. The VRTX/sa profile should be too, even > if more recent than the VRTX32 one. > - the uITRON skin is a prototype; I don't know if it has even run > anywhere. It aims at conforming to the 3.0 specs, and at implementing > the 'E'-level support, along with a few strictless but convenient calls > from levels 'S' and 'R'. > - the POSIX skin is in good shape; it aims at conforming to the PSE51 > profile. > > o Use in real projects > > To my knowledge, the pSOS skin has been used a few times already (3/4) > in porting embedded code that used to run on MVME141 boards to Linux. I > never saw the code, just heared about the porting effort. > The VRTX and VxWorks skins have been used at least once for a first > order port to Linux, the plan being to convert all the API calls to > POSIX later. Maybe (probably?) the people involved into these ports had > to fix rough edges, but if they did, I cannot tell which ones, because I > did not receive any patches, so... > > To sum up, using those skins is still a pioneering effort; this said, > the core that underlies all of them (i.e. the nucleus) is constantly > refined since 2001 and in use in some significant projects now (e.g. > Hyades), so would some problems arise, they should mainly concern the > skin(s) (i.e. the "window dressing" part, not the core). Additionally, > the bonus is that those skins all run over the simulation engine, so > finding bugs there is much more simple and efficient. Of course, one has > to remove the arch-dep sections of the original code and possibly > provides for stubs here and there, but the former is already a task that > needs to be done when migrating to another hw anyway, so there is no > loss of time. > >> - Fusion is based on Linux 2.6, ADEOS and Xenomai. Does it make sense to >> use the "old" skins also for Linux 2.4, which are currently available >> in the kileau and vesuvio branch. > > Since they are based on the nucleus interface which has not changed > (except for details), they will work the same way in 3.x and fusion, > yes. Prefer 3.1 though, it has received more attention wrt backporting > fixes applied to fusion than 3.0. > >> Hope I have not confused terms like Xenomai, Fusion, Skins too much. >> > > Looks ok.
OK, now the status is cleared to me. And what's about debugging with GDB? I think it's not possible to properly debug a RTAI/LXRT application because LXRT runs a kernel module in user space. Will this change with RTAI/fusion? Thanks. Wolfgang.
