Re: [Xenomai] Packaging Xenomai-3

[Daniele Nicolodi <daniele@grinta.net>]

Hello Leopold,

it seems to me that you are missing a few key points.

On 26/01/15 13:39, Leopold Palomo-Avellaneda wrote:
>> This is a decision that upstream should not impose to all users.
> 
> Interesting sentence. You are developing a new version with an step forward. 
> You have reworked libraries and for instance libxenomai, libnative, librtdm 
> doesn't exists in Xenomai-3. Also you have introduced new ones (libalchemy, 
> libcobalt, libcopperplate, libtrank. 
> 
> You have developed xenomai in two main group of libraries (or use a cobalt 
> kernel or a mercury kernel) and are you saying that you cannot impose to all 
> users a suffix or something that the users could have both version co-
> installed in standards places in their systems?

The APIs provided by Xenomai on top of the regular Linux kernel
interface are only for smoothing the porting of legacy application
written using the APIs peculiar to other RTOS and which Xenomai implements.

Ideally any new development should be done with the POSIX APIs.

The choice between cobalt or mercury is demanded by the real time
requirements of the specific application and the target hardware. It
cannot be a user configuration.

>> Only users with your specific needs should do what you want. 
> 
> Maybe I'm wrong. But after reading this thread I understood that to have a 
> kernel with both patches (i-pipe and preempt_rt) and, I understand, Xenomai-3 
> with the two versions could be a very interesting system to work on.
> 
> For instance, I'm in the robotics field, and after that mails I thought that 
> it could be a good solution that fit the cases where you have several loops, 
> with several rates with different importance.

Several loops with several rates with different importance must be
mapped to tasks with different priorities. It does not make sense to
have them mapped to threads running in different modes.

> Not really. It's nice if you a have a package.

If this if of such prominent importance for you, I suggest it to code
this yourself. It does not make sense to argue with upstream that this
feature is useful, especially with arguments that seems to indicate that
you do not have a complete understanding of the issue, neither that you
tried it and it effectively solves some real problems.

Cheers,
Daniele