Re: [Xenomai-core] uvm/vxworks and uvm/vrtx are still being built
On Thu, 2006-07-20 at 00:08 +0200, Jan Kiszka wrote: > Philippe Gerum wrote: > > ... > > To sum up, the UVM support is hard to explain to potential users, adds a > > fair amount of confusion when compared to using the direct syscall > > interfaces from user-space, and can't evolve up to the point where I > > could be happy with them. > > > > Thanks for clarifying. I never looked that deep into the UVM (except > when I broke something with an arch patch). I just wrote that mail while > waiting on the user-space part for being built ;). The UVM lib is > default=y, maybe something we should change soon as well. True. It's going to be tagged as deprecated in 2.2.1, and switched off by default. > > > PS: regarding the RTAI issue, most projects migrating from there to Xeno > > are AFAIK, converting their applications to use the native skin > > directly, or even the POSIX one. Fact is that RTAI is more than 300 > > calls, if you take into account all the interface variants. Given the > > nature of what is actually a set of APIs, more than a single one, the > > sandboxed environment the UVM brings does not fit the RTAI interfaces at > > all. People really interested in having a 100% compatible RTAI skin over > > Xenomai that accurately emulates LXRT should definitely implement the > > direct syscall interface for it. > > > > AFAIK no one insisted yet on user-space support for the RTAI skin. So > this seconds that porting actually takes place at the application level. > I guess it would take a rather large RTAI app so that writing a really > compatible skin becomes worth the effort. > Same views here. > Jan > -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] uvm/vxworks and uvm/vrtx are still being built
Philippe Gerum wrote: > ... > To sum up, the UVM support is hard to explain to potential users, adds a > fair amount of confusion when compared to using the direct syscall > interfaces from user-space, and can't evolve up to the point where I > could be happy with them. > Thanks for clarifying. I never looked that deep into the UVM (except when I broke something with an arch patch). I just wrote that mail while waiting on the user-space part for being built ;). The UVM lib is default=y, maybe something we should change soon as well. > PS: regarding the RTAI issue, most projects migrating from there to Xeno > are AFAIK, converting their applications to use the native skin > directly, or even the POSIX one. Fact is that RTAI is more than 300 > calls, if you take into account all the interface variants. Given the > nature of what is actually a set of APIs, more than a single one, the > sandboxed environment the UVM brings does not fit the RTAI interfaces at > all. People really interested in having a 100% compatible RTAI skin over > Xenomai that accurately emulates LXRT should definitely implement the > direct syscall interface for it. > AFAIK no one insisted yet on user-space support for the RTAI skin. So this seconds that porting actually takes place at the application level. I guess it would take a rather large RTAI app so that writing a really compatible skin becomes worth the effort. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] uvm/vxworks and uvm/vrtx are still being built
On Wed, 2006-07-19 at 02:08 +0200, Jan Kiszka wrote: > ...intentionally? I thought those two UVM components were obsoleted by > the full user-space skin support. > They are now obsolete, but a smooth transition requires to have both in 2.2, so that people having based some development over the UVM could get a grace period before the UVM support is eventually removed. v2.2.1 will mark it as deprecated in the configuration section. > On the other hand, the rtai user-space back- and front-end look a bit > "premature". Wouldn't it be better to feed this skin into the UVM build > process meanwhile? In fact, the UVM support is going to be removed from 2.3. The rationale behind this is: 1- the UVM support was intended as being a work-around, so that skins without direct syscall interface from user-space to the skin module could still be usable in regular process context (i.e. and not only from a kernel module). Now that the majority of the in-tree skins has been given such interface, keeping the UVM support is indeed useless. 2- Because of #1, the UVM has some limitations, mainly due to design issues. For instance, it's not possible to sanely and safely mix uses of sandboxed skins running over a UVM with a regular skin, like the POSIX or native ones. There are synchonization issues, which cannot be solved without going for utterly overkill solutions. On the other hand, such mix is perfectly fine with skins exhibiting a direct syscall interface to their implementation module. 3- Now that the VxWorks skin has a direct call interface to the kernel module, and provided that we are going to implement the pSOS and uITRON counterparts, there is no sign on the mailing list that many people would depend on the UVM anymore. 4- Maintaining the UVM - as a Xenomai pseudo-architecture - is a pure PIA, with no reward, since it brings nothing more that normal user-space callable skins, but actually much less, due to their sandboxed runtime environment (e.g. one has hard time writing kernel space support to extend a UVMed skin). To sum up, the UVM support is hard to explain to potential users, adds a fair amount of confusion when compared to using the direct syscall interfaces from user-space, and can't evolve up to the point where I could be happy with them. PS: regarding the RTAI issue, most projects migrating from there to Xeno are AFAIK, converting their applications to use the native skin directly, or even the POSIX one. Fact is that RTAI is more than 300 calls, if you take into account all the interface variants. Given the nature of what is actually a set of APIs, more than a single one, the sandboxed environment the UVM brings does not fit the RTAI interfaces at all. People really interested in having a 100% compatible RTAI skin over Xenomai that accurately emulates LXRT should definitely implement the direct syscall interface for it. -- Philippe. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] uvm/vxworks and uvm/vrtx are still being built
...intentionally? I thought those two UVM components were obsoleted by the full user-space skin support. On the other hand, the rtai user-space back- and front-end look a bit "premature". Wouldn't it be better to feed this skin into the UVM build process meanwhile? Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
