Re: [Xenomai] Packaging Xenomai-3

[Leopold Palomo-Avellaneda <leo@alaxarxa.net>]

El Dilluns, 26 de gener de 2015, a les 14:38:00, Daniele Nicolodi va escriure:
> Hello Leopold,
> 
> it seems to me that you are missing a few key points.

Probably. Thanks for helping me to understand it.

> 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.

I'm not talking about user configuration. AFAIK the idea is that you can 
compile and link your code (without any change) again the library built to 
work cobalt or mercury. No that the user config it in runtime.

> >> 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.

this is one option. But many times you work on software provides by others and 
modify it is not affordable.

> > 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.

Maybe I didn't choose a perfect reference about with robotic field. But I 
don't think that it's fair to disqualifying my arguments me about my propose.

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150126/3a66b092/attachment.sig>