Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Steven Seeger]

Philippe, as we have previously discussed I am willing to take over the PPC i-
pipe maintenance on my personal time if it will help. My only issue is right 
now the only PPC board I have in my posseession is an 8548-based board. I 
might be able to borrow some 405 and 440-based boards from work if needed. Of 
course, we can always depend on the grateful Xenomai users for test and 
feedback. :)

I am not sure my group is going to pursue RTNET otherwise I would have been 
happy to help there. I think negotations are still open on that one, though.

If we ever get around to releasing my microblaze i-pipe patch then I am happy 
to maintain that as well. :) Feel free to email me privately if you want to 
discuss.

I really miss Gilles and maybe I can help carry on his memory in some small 
way. Hopefully he is in heaven where there are no geode CPUs to chase FPU bugs 
on :)

Steven

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

Hi Steven,

On 11/22/2017 05:49 PM, Steven Seeger wrote:
> Philippe, as we have previously discussed I am willing to take over the PPC i-
> pipe maintenance on my personal time if it will help.

Thanks, that would be great.

 My only issue is right
> now the only PPC board I have in my posseession is an 8548-based board. I 
> might be able to borrow some 405 and 440-based boards from work if needed. Of 
> course, we can always depend on the grateful Xenomai users for test and 
> feedback. :)
>

I have remote access to many ppc boards and could help here. This said
85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
- maybe adding mpc52xx would be good, I have one here. I don't see much
traction these days for Xenomai over ppc64, so I'm not even sure whether
this port is still relevant.

> I am not sure my group is going to pursue RTNET otherwise I would have been 
> happy to help there. I think negotations are still open on that one, though.
> 
> If we ever get around to releasing my microblaze i-pipe patch then I am happy 
> to maintain that as well. :) Feel free to email me privately if you want to 
> discuss.

Ok.

> 
> I really miss Gilles and maybe I can help carry on his memory in some small 
> way. Hopefully he is in heaven where there are no geode CPUs to chase FPU bugs 
> on :)


-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Steven Seeger]

> Hi Steven,
> 
> I have remote access to many ppc boards and could help here. This said
> 85xx, 40x and 44x already cover much of the ppc32 scope running Xenomai
> - maybe adding mpc52xx would be good, I have one here. I don't see much
> traction these days for Xenomai over ppc64, so I'm not even sure whether
> this port is still relevant.

I have never used ppc64 so I would take some time coming up to speed with it 
(and would need access to a board.) I am sure you can tell from all our 
private emails over the last couple years that I wouldn't have a problem with 
ppc32. 

I am unsure how remote access to boards works especially at this level of 
work. Is there some way to power on and off if needed or do they depend on a 
watchdog? We can discuss this offline.

Steven

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Le 01/12/2017 à 16:09, Stéphane Ancelot a écrit :
>
>
> Le 25/11/2017 à 21:32, Philippe Gerum a écrit :
>> On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
>>> The xenomai API is not enough documented in order to permit new
>>> developer's entry.
>> Can you elaborate on what could be done to improve the documentation,
>> according to your own experience with it?
> It is difficult to understand which version / release to use ?
> Difference between what is stable / unstable is not really clear.
> I lost many times using some versions, then trying another one, 
> because of some bugs .....
> And finally at a moment, in real life, altough you may know  there are 
> some problems in the implementation you are using, you must stick to a 
> version, you have delivery date....
>
>
> When you read the docs , you are in front of "new" terms : cobalt / 
> mercury, alchemy ... that's a bit confusing mixing everything in the 
> right order. Do I need it, or not ?
> what is the right guideline ?
> You have to brainstorm yourself to understand what is cobalt, how it 
> is working, the added value .
> What will I use ?
>
EDIT :
> next , there are many API (alchemy, cobalt, psos, vxworks ,posix ...), 
> you may face some bugs, so, you try it in another API, luckily if it 
> works, you change your code and mix api !!!
> Many api imply more complexity and  maintenance, are all these API 
> really mandatory ?????
>
>
>>> Targetting and permitting students to contribute could be a good 
>>> benefit.
>>>
>> How would you do that?
>>
>>> Unit tests cases seem mandatory .
>>>
>> There are (testsuite/smokey), but clearly not enough of them though.
>>
>
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Le 25/11/2017 à 21:32, Philippe Gerum a écrit :
> On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
>> The xenomai API is not enough documented in order to permit new
>> developer's entry.
> Can you elaborate on what could be done to improve the documentation,
> according to your own experience with it?
It is difficult to understand which version / release to use ?
Difference between what is stable / unstable is not really clear.
I lost many times using some versions, then trying another one, because 
of some bugs .....
And finally at a moment, in real life, altough you may know  there are 
some problems in the implementation you are using, you must stick to a 
version, you have delivery date....


When you read the docs , you are in front of "new" terms : cobalt / 
mercury, alchemy ... that's a bit confusing mixing everything in the 
right order. Do I need it, or not ?
what is the right guideline ?
You have to brainstorm yourself to understand what is cobalt, how it is 
working, the added value .
What will I use ?

next , there are many API (alchemy, cobalt, psos, vxworks ,posix ...), 
luckily if it works, you change your code and mix api !!!
Many api imply more complexity and  maintenance, are all these API 
really mandatory ?????


>> Targetting and permitting students to contribute could be a good benefit.
>>
> How would you do that?
>
>> Unit tests cases seem mandatory .
>>
> There are (testsuite/smokey), but clearly not enough of them though.
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Hi,

This may be offtopic regarding xenomai itself.

But, I am a member of the kde community, which is very active.Recently, 
they made some proposals to improve onboarding of new contributors.

I think there are some very good ideas that can apply here, here is the 
link.

https://phabricator.kde.org/T7116

Regards,

S.Ancelot


Le 21/11/2017 à 18:11, Philippe Gerum a écrit :
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jorge Ramirez]

On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
> Hi guys,
>
> Here at Numalliance, as xenomai development contributors and users, we 
> can  give only a quick reply to some points at the moment :
>
> Regarding irc/mailing lists , we would prefer tools like  Discord, 
> that is a modern,very  good collaborative and interactive tool to 
> discuss subjects.Using either text or voice channels.
> You will not attract young people generation with IRC .

IMO those recent graduates will be attracted by the technology itself - 
they will be able to do things - and create businesses - that others 
can't do without Xenomai/RT support.

and besides, should first agree on having a mailing list and a channel 
and then decide on the best channel?
Even though I agree with you (I want a channel :) ) It seems most of the 
folks in the ML are mostly interested in off-line discussions anyway.

>
> an issue tracker would be mandatory in order to :
> * identify problems and permit resolution to anyone wanting  to 
> contribute and solve it
> * link issues with the software repository and resolution (back and 
> forth) , (we are using redmine )
> * history tracking

I still dont think an issue tracker is necessary (but my opinion is 
obviously as good as any).
I would much rather have a kanban board with a 10 mile view of the 
project. That is easy to maintain.

>
> I know many opensource projects are using stackoverflow  as main 
> website support  .
> It permits knowledge sharing.
> Questions/Replies  are often reviewed by other people and thus 
> filtered if questions need clarifying or duplicated issues ...

I think that is what the ML is for. Xenomai doesnt have the resources 
(AFAIK) to maintain something like we have in 96boards [1]

>
> The xenomai API is not enough documented in order to permit new 
> developer's entry.
> Targetting and permitting students to contribute could be a good benefit.

absolutely.

>
>
> Unit tests cases seem mandatory .

agree


[1] https://discuss.96boards.org/

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/24/2017 11:46 AM, Stéphane Ancelot wrote:
> The xenomai API is not enough documented in order to permit new
> developer's entry.

Can you elaborate on what could be done to improve the documentation,
according to your own experience with it?

> Targetting and permitting students to contribute could be a good benefit.
>

How would you do that?

> Unit tests cases seem mandatory .
> 

There are (testsuite/smokey), but clearly not enough of them though.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane Ancelot]

Hi guys,

Here at Numalliance, as xenomai development contributors and users, we 
can  give only a quick reply to some points at the moment :

Regarding irc/mailing lists , we would prefer tools like  Discord, that 
is a modern,very  good collaborative and interactive tool to discuss 
subjects.Using either text or voice channels.
You will not attract young people generation with IRC .

an issue tracker would be mandatory in order to :
* identify problems and permit resolution to anyone wanting  to 
contribute and solve it
* link issues with the software repository and resolution (back and 
forth) , (we are using redmine )
* history tracking

I know many opensource projects are using stackoverflow  as main website 
support  .
It permits knowledge sharing.
Questions/Replies  are often reviewed by other people and thus filtered 
if questions need clarifying or duplicated issues ...

The xenomai API is not enough documented in order to permit new 
developer's entry.
Targetting and permitting students to contribute could be a good benefit.

Unit tests cases seem mandatory .


Regards,
S.Ancelot

Le 21/11/2017 à 18:11, Philippe Gerum a écrit :
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane LOS]

Hi,

Wouldn't integrating both projects make sense ?

It seems both share a significant amount of work and similar lack of 
resources.

Sorry, talking about the "Real Time Linux" project and "Xenomai"...

And sorry for the noise added automagically to my emails. :-(
I should use some other mail account.

Best Regards,
Cordialement,

Stéphane LOS
slos@hilscher.com
Support technique

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hilscher France
12, rue du 35ème Régiment d'Aviation
Miniparc du Chêne
69500 BRON
France
Tél. : +33 (0) 4 72 37 98 40
Fax  : +33 (0) 4 78 26 83 27
http ://www.hilscher.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Le 24/11/2017 à 09:52, Stéphane LOS a écrit :
> Hi,
>
> Wouldn't integrating both projects make sense ?
>
> It seems both share a significant amount of work and similar lack of 
> resources.
>
> Best Regards,
> Cordialement,
>
> Stéphane LOS
> slos@hilscher.com
> Support technique
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Hilscher France
> 12, rue du 35ème Régiment d'Aviation
> Miniparc du Chêne
> 69500 BRON
> France
> Tél. : +33 (0) 4 72 37 98 40
> Fax  : +33 (0) 4 78 26 83 27
> http ://www.hilscher.fr
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Le 23/11/2017 à 21:45, Philippe Gerum a écrit :
>> On 11/22/2017 09:26 PM, Jan Kiszka wrote:
>>> On 2017-11-21 18:11, Philippe Gerum wrote:
>>>> So, let's talk about the elephant in the room: the current 
>>>> situation of
>>>> the Xenomai project is not viable in the long run. I can only 
>>>> encourage
>>>> people who feel concerned about it to discuss openly the practical 
>>>> steps
>>>> to best address this challenge.
>>> Thanks for bringing this frankly on the table! For those who follow the
>>> project, it's likely no news. So we were working on this issue also
>>> internally, with users of Xenomai inside Siemens. And we have the
>>> backing to enhance our involvement in upstream work. Right now we are
>>> working on making this concrete.
>>>
>>> There are many areas where contributions can be beneficial for the
>>> project and its community, and many do not require deepest 
>>> understanding
>>> of the core, like around CI, test automation, distro packaging,
>>> documentation, or user support. But some essential elements in my 
>>> eyes are
>>>
>>>   - building up a core team of kernel maintainers for Cobalt
>>>
>>>   - offloading work from the shoulders of our extremely valuable
>>>     maintainer
>>>
>>> The second part will be achieved to a certain degree by the first 
>>> one as
>>> Philippe can probably confirm.
>> Yes, extending "Cobalt" to the pipeline. A significant portion of the
>> overall maintenance involves the I-pipe. Hence the work on rethinking
>> how the interrupt pipeline is integrated into the Linux kernel, how we
>> can make the former a regular feature of the latter instead of an
>> add-on, with the goal of simplifying the maintenance, but also making
>> the whole thing way more natural, easier to grasp.
>>
>



Hilscher France S.a.r.l.   |  12, rue du 35ième Régiment d’Aviation – Miniparc du Chêne  |  69500 Bron  |  France  |  www.hilscher.com
Hot Line: +33 (0) 472 379 843  |  Centre de formation agréé  |  RandD: +33 (0) 472 379 840
N° de TVA intracommunautaire: FR 43 449 481 779  |  N° de SIRET: 449 481 779 00014
Dirigeant: Christophe Levra

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Hilscher cannot be held responsible of whatever nature, resulting from alteration, falsifying or using of the information contained in this message and disclaims all liability in case of contamination of the computer hardware of the addressee resulting from the distribution of a virus or other computing infections.


Information Importante:
Ce message électronique incluant les pièces jointes contient des informations confidentielles et protégées par la loi qui sont à l’intention exclusive de son destinataire. Si vous n'êtes pas le destinataire  de ce message, merci de contactez immédiatement l'expéditeur et de supprimer ce message incluant les pièces jointes. Toute diffusion ou copie ou modification de ce message électronique, totale ou partielle, non autorisée est strictement interdit. L'expéditeur ne peut être tenu responsable du contenu de tels messages électroniques qui auraient été modifies.

Hilscher ne pourra être tenue responsable de quelque dommage, de quelque nature qu’il soit, résultant de l’altération, de la falsification ou de l’utilisation des informations contenues dans ce message et décline toute responsabilité en cas de contamination des matériels informatiques du destinataire résultant de la propagation d'un virus ou autres infections informatiques.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Stéphane LOS]

Hi,

Wouldn't integrating both projects make sense ?

It seems both share a significant amount of work and similar lack of 
resources.

Best Regards,
Cordialement,

Stéphane LOS
slos@hilscher.com
Support technique

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hilscher France
12, rue du 35ème Régiment d'Aviation
Miniparc du Chêne
69500 BRON
France
Tél. : +33 (0) 4 72 37 98 40
Fax  : +33 (0) 4 78 26 83 27
http ://www.hilscher.fr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Le 23/11/2017 à 21:45, Philippe Gerum a écrit :
> On 11/22/2017 09:26 PM, Jan Kiszka wrote:
>> On 2017-11-21 18:11, Philippe Gerum wrote:
>>> So, let's talk about the elephant in the room: the current situation of
>>> the Xenomai project is not viable in the long run. I can only encourage
>>> people who feel concerned about it to discuss openly the practical steps
>>> to best address this challenge.
>> Thanks for bringing this frankly on the table! For those who follow the
>> project, it's likely no news. So we were working on this issue also
>> internally, with users of Xenomai inside Siemens. And we have the
>> backing to enhance our involvement in upstream work. Right now we are
>> working on making this concrete.
>>
>> There are many areas where contributions can be beneficial for the
>> project and its community, and many do not require deepest understanding
>> of the core, like around CI, test automation, distro packaging,
>> documentation, or user support. But some essential elements in my eyes are
>>
>>   - building up a core team of kernel maintainers for Cobalt
>>
>>   - offloading work from the shoulders of our extremely valuable
>>     maintainer
>>
>> The second part will be achieved to a certain degree by the first one as
>> Philippe can probably confirm.
> Yes, extending "Cobalt" to the pipeline. A significant portion of the
> overall maintenance involves the I-pipe. Hence the work on rethinking
> how the interrupt pipeline is integrated into the Linux kernel, how we
> can make the former a regular feature of the latter instead of an
> add-on, with the goal of simplifying the maintenance, but also making
> the whole thing way more natural, easier to grasp.
>



Hilscher France S.a.r.l.   |  12, rue du 35ième Régiment d’Aviation – Miniparc du Chêne  |  69500 Bron  |  France  |  www.hilscher.com
Hot Line: +33 (0) 472 379 843  |  Centre de formation agréé  |  RandD: +33 (0) 472 379 840
N° de TVA intracommunautaire: FR 43 449 481 779  |  N° de SIRET: 449 481 779 00014
Dirigeant: Christophe Levra

Important Information:
This e-mail message including its attachments contains confidential and legally protected information solely intended for the addressee. If you are not the intended addressee of this message, please contact the addresser immediately and delete this message including its attachments. The unauthorized dissemination, copying and change of this e-mail are strictly forbidden. The addresser shall not be liable for the content of such changed e-mails.

Hilscher cannot be held responsible of whatever nature, resulting from alteration, falsifying or using of the information contained in this message and disclaims all liability in case of contamination of the computer hardware of the addressee resulting from the distribution of a virus or other computing infections.


Information Importante:
Ce message électronique incluant les pièces jointes contient des informations confidentielles et protégées par la loi qui sont à l’intention exclusive de son destinataire. Si vous n'êtes pas le destinataire  de ce message, merci de contactez immédiatement l'expéditeur et de supprimer ce message incluant les pièces jointes. Toute diffusion ou copie ou modification de ce message électronique, totale ou partielle, non autorisée est strictement interdit. L'expéditeur ne peut être tenu responsable du contenu de tels messages électroniques qui auraient été modifies.

Hilscher ne pourra être tenue responsable de quelque dommage, de quelque nature qu’il soit, résultant de l’altération, de la falsification ou de l’utilisation des informations contenues dans ce message et décline toute responsabilité en cas de contamination des matériels informatiques du destinataire résultant de la propagation d'un virus ou autres infections informatiques.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 09:26 PM, Jan Kiszka wrote:
> On 2017-11-21 18:11, Philippe Gerum wrote:
>> So, let's talk about the elephant in the room: the current situation of
>> the Xenomai project is not viable in the long run. I can only encourage
>> people who feel concerned about it to discuss openly the practical steps
>> to best address this challenge.
> 
> Thanks for bringing this frankly on the table! For those who follow the
> project, it's likely no news. So we were working on this issue also
> internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.
> 
> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest understanding
> of the core, like around CI, test automation, distro packaging,
> documentation, or user support. But some essential elements in my eyes are
> 
>  - building up a core team of kernel maintainers for Cobalt
> 
>  - offloading work from the shoulders of our extremely valuable
>    maintainer
> 
> The second part will be achieved to a certain degree by the first one as
> Philippe can probably confirm.

Yes, extending "Cobalt" to the pipeline. A significant portion of the
overall maintenance involves the I-pipe. Hence the work on rethinking
how the interrupt pipeline is integrated into the Linux kernel, how we
can make the former a regular feature of the latter instead of an
add-on, with the goal of simplifying the maintenance, but also making
the whole thing way more natural, easier to grasp.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 09:27 PM, Jan Kiszka wrote:
> On 2017-11-22 16:32, Philippe Gerum wrote:
>>
>> Hi Kendall,
>>
>> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>>> Hi Philippe,
>>>
>>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>>
>>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>>
>> We don't have that unfortunately. As suggested by several posters,
>> moving to a git-based, integrated development framework such as gitlab
>> or github would bring in that feature, and others we need too (CI).
>>
>> I have no issue moving the project from the current git server at
>> xenomai.org to any of these environments.
>>
> 
> If it helps the community to grow, I would not refuse such a move. But I
> would like to raise some concerns about platforms like github or gitlab
> that we must be aware of:
> 
> - lacking integration with email-based workflows (while kernel
>   development tends to be based on that...)
> 
> - risk of decoupling communities when parts of the discussions happen on
>   tickets or PRs and parts in mailing list threads
> 
> Therefore, most projects I manage on github and in our internal gitlab
> have clear policies like "no emails, only tickets and PRs" or "no PRs,
> only patches on the mailing list". Even just using the issue tracker to
> keep some to-do list requires discipline to direct discussions
> consequently to a mailing list if that exists as well (and that usually
> does not work very well).
> 
> IOW: we need to be clear in what we want a platform for - and what not.
> 

Defining the process first may help, then we could certainly find a tool
that fits the requirement. AFAICT, reports from users and maintainers
mainly fall into these categories:

- perceived runtime bugs (confirmed or not)
- configuration, installation problems
- request for change, improvements

Reports about runtime bugs should be posted to mailing list first,
unless they have been directly observed by a subsystem maintainer. If
the issue is confirmed, it should be logged into the tracker by the
concerned subsystem maintainer. Many users report bugs which have
already been solved, the tracker should help making the solution visible
for closed issues, or maybe we'd need another way to bring up that
information to the attention of users.

Request for changes should translate into RFCs to the mailing list so
they can be discussed, last but not least to prevent duplicate effort
with potentially ongoing work. A detailed description of what is
needed/planned could then be published to a dedicated section of the web
site in free form; this would contribute to the general TODO list Greg
mentioned earlier.

Questions about configuration and installation can be efficiently dealt
with good documentation (TBD) and a mailing list.

To get this process working, I don't think we'd need more than a tracker
with write access to subsystem maintainers only (once we have some, that
is), and the existing mailing list, which should prevent crosstalk.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Giulio Moro]

At Bela (bela.io) we use Xenomai on the BeagleBone Black for audio. Currently our resources are pretty scarce, but hopefully from March things should get better For instance, now that RobertCNelson has discontinued support for Xenomai on the BeagleBone, we may be able to help with that (incidentally - as someone was asking - we provide a pre-built image for BeagleBone with Debian Stretch and  Xenomai 3.0.5 on Linux 4.4 (and some of our stuff too): https://github.com//BelaPlatform/bela-image-builder/releases).

> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely

Either way, it would be great to be able to take part in this workshop with Philippe. I think it is unlikely that we would be able to travel to Munich in January, but we should be able to attend remotely, so please keep us in the loop. I reckon it would be important (if all the involved parties agree, that is) to make a video recording of the workshop available online for posterity (e.g.: a youtube live streaming and subsequently available permanently), so to make it easier for others in the future to get started with Xenomai's development.

Thanks,
Giulio

________________________________________
From: Xenomai <xenomai-bounces@xenomai.org> on behalf of Henning Schild <henning.schild@siemens.com>
Sent: 23 November 2017 12:21
To: Jan Kiszka
Cc: Daniel Wagner; Xenomai@xenomai.org
Subject: Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.
>
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.

> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
>
>  - building up a core team of kernel maintainers for Cobalt
>
>  - offloading work from the shoulders of our extremely valuable
>    maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
>
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
>
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and integration paths
>  - update strategy and frequency
>  - testing needs and strategies
>  - supportable architectures
>  - state and details of the new pipeline design
>  - planning of and migration path to the new design
>
> If there is interest in joining such a discussion, physically (will
> likely take place in our office in Munich, Germany) or virtually
> (provided time zones work out), please let us know. Time frame is more
> likely early next year than mid of this December. And this shall be
> only the kickoff for further discussions in the community!

Yes, anyone that wants to join such a meeting please let us know.
Depending on the feedback we could also arrange something different.
(i.e. collocated with FOSDEM18? )

Henning

> Jan
>


_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Henning Schild]

Am Wed, 22 Nov 2017 21:26:23 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:

> On 2017-11-21 18:11, Philippe Gerum wrote:
> > So, let's talk about the elephant in the room: the current
> > situation of the Xenomai project is not viable in the long run. I
> > can only encourage people who feel concerned about it to discuss
> > openly the practical steps to best address this challenge.  
> 
> Thanks for bringing this frankly on the table! For those who follow
> the project, it's likely no news. So we were working on this issue
> also internally, with users of Xenomai inside Siemens. And we have the
> backing to enhance our involvement in upstream work. Right now we are
> working on making this concrete.

I could not agree more, thanks for bringing that up!

I will also be frank and put my thoughts on the table. The most
important point on our tasks to work on is culture. Technical details
and who does what can be addressed later or along the way.

IMHO Xenomai is not an open-source project. There is no open agenda, no
TODO list, issue tracking, discussions etc. All this critical
information, along with the hardcore technical details, used to be in
the heads of two people + plus a few others guessing and helping out a
bit. Now we are down to 1 + for quite a while. Still very much top-down
instead of open.

Looking at the project today nobody could tell where to start
contributing. Nobody knows when the next branch will pop up in git or
the next release will fall from the sky. Such things are not discussed,
they just happen.

Ok, now that was me expressing personal opinions and impressions, not
addressing blame.

I am convinced that a lot of this information can be opened up, maybe
with the use of tools (issue trackers etc.). Now for the experience and
the skills we desperately need Philippe to change his role to being
more of a mentor. And i will be happy to work on tasks that are
assigned to me, my solutions will lack speed and quality at first but
that will hopefully change over time.
 
> There are many areas where contributions can be beneficial for the
> project and its community, and many do not require deepest
> understanding of the core, like around CI, test automation, distro
> packaging, documentation, or user support. But some essential
> elements in my eyes are
> 
>  - building up a core team of kernel maintainers for Cobalt
> 
>  - offloading work from the shoulders of our extremely valuable
>    maintainer

We (Siemens) can help with 1 and therefore 2. ...for now. But adding a
few people to the inner circle will not do the trick. Especially not if
these people are coming from industry and only one player. The
dedication/funding of industry players by enlarge depends on business
decisions that are valid for one fiscal year.
But industry is the largest user of xenomai, so to mitigate that
problem more players are needed!

> The second part will be achieved to a certain degree by the first one
> as Philippe can probably confirm. So I would like to focus this and
> try to make some first step:
> 
> We are currently planning a so far internal workshop with Philippe in
> order to discuss how to bring more of our people but also others on
> board regarding kernel maintenance topics. Topics to discussed are
> likely
> 
>  - current design and how to introduce people to it (tough, yeah...)
>  - possible workflows and integration paths
>  - update strategy and frequency
>  - testing needs and strategies
>  - supportable architectures
>  - state and details of the new pipeline design
>  - planning of and migration path to the new design
> 
> If there is interest in joining such a discussion, physically (will
> likely take place in our office in Munich, Germany) or virtually
> (provided time zones work out), please let us know. Time frame is more
> likely early next year than mid of this December. And this shall be
> only the kickoff for further discussions in the community!

Yes, anyone that wants to join such a meeting please let us know.
Depending on the feedback we could also arrange something different.
(i.e. collocated with FOSDEM18? )

Henning

> Jan
> 

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 01:33 PM, Leopold Palomo-Avellaneda wrote:

[snip]

> 
> And finally, if you let me talk about our Elmer.
> 
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people have
> interest.
>

For the record, I'm definitely not suggesting to drop all I/O device
support from Xenomai, that would obviously make no sense. However, the
broken code must be fixed otherwise it serves no purpose but annoying
both users and maintainers.

> But I would like to ask you directly Philippe some practical steps that could
> address to this challenge:
> 
> - Would you be willing to move Xenomai to some platform like github, or similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
> 

Yes.

> - Would you be willing to delegate tasks of the project to other people,

Yes.

 that
> maybe will not make it as good as you will do, like documentation, web site, or
> parts of code, but made then with an acceptable quality?

Yes. This said, acceptable quality is a matter of taste and perception,
and the people involved in the merging process may have different views
on this. Fortunately for us, crap always solidly looks crap, which eases
the decision process when deciding what to do with it.

 And please, don't take
> bad, it's a difficult thing. I have to confess that for me, it's very difficult.
> > - Would you be willing to guide new contributors and give them
responsibilities
> of important parts of the code?
> 

Yes. However, we cannot expect anyone to decide for us what we could be
interested in contributing. What needs to be done can be put on the
table for discussion, people may add new ideas, but at the end of the
day, one is responsible for committing to a task.

> - Would you be willing to have the role as coordinator and leader of the project
> changing from one man show to some more open project? will be it possible? I

This is already the situation today, the real issue is that I'm
contributing most of the code, and have to carry out all of the other
tasks in the project, which ends up with nothing being done with the
required level of predictability and quality.

Even more importantly, most of the knowledge about how things work
internally all across the core system over all CPU architectures is
dangerously concentrated into a single person's brain. With a bus factor
of 1, well, Houston, we have a problem.

Information must flow, as a matter of fact, it does not, at the very
least not enough. This is clearly not a matter of unwillingness from my
end, but I tend to get lazy writing documentation about the internal
stuff when I'm not explicitly challenged to provide information by
people involved in the project.

> don't know if because license issues or whatever would let it...
>

The licensing scheme is very simple (fully abide by the kernel GPL
license for anything living in kernel space, use LGPL for libs in
userland) and did not change for the past 15 years, I'm not aware of any
issue so far.

> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a barrier
> for the new contributors, at least in another opensource projects. However, I
> have to admit that the entry level in Xenomai is high, so, autotools should not
> be a problem.

I'm not excluding any change at this stage, which includes considering
other options in replacement of the autotools. This said, I don't think
the tool supporting build recipes can prevent anyone to contribute
software. In kernel space, Kbuild has to be followed and autotools are
not involved at all. In user-space, a recipe to build an exec or a
library is about 10 lines of a Makefile template, with many examples
around. And the mailing list has always been there for people to ask
specific questions about this.

> 
> And yes, the lost of Gilles was a great blow, on a the personal level and for
> his contributions on the project.
> 
>>From my part, I can contribute if there's interest, in Debian (Ubuntu) packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm. So, I
> could try to provide some preconfigured scenarios to the people that would like
> to entry in Xenomai.
> 
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to RT_PREMPT. But,
> because its history and my "affection" for the project I would prefer stay with
> it and try to help.
> 

Talking about the elephant in the room does not make it scarier, it has
always been there.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jan Kiszka]

On 2017-11-22 16:32, Philippe Gerum wrote:
> 
> Hi Kendall,
> 
> On 11/21/2017 08:27 PM, Auel, Kendall wrote:
>> Hi Philippe,
>>
>> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
>>
>> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
>>
> We don't have that unfortunately. As suggested by several posters,
> moving to a git-based, integrated development framework such as gitlab
> or github would bring in that feature, and others we need too (CI).
> 
> I have no issue moving the project from the current git server at
> xenomai.org to any of these environments.
> 

If it helps the community to grow, I would not refuse such a move. But I
would like to raise some concerns about platforms like github or gitlab
that we must be aware of:

- lacking integration with email-based workflows (while kernel
  development tends to be based on that...)

- risk of decoupling communities when parts of the discussions happen on
  tickets or PRs and parts in mailing list threads

Therefore, most projects I manage on github and in our internal gitlab
have clear policies like "no emails, only tickets and PRs" or "no PRs,
only patches on the mailing list". Even just using the issue tracker to
keep some to-do list requires discipline to direct discussions
consequently to a mailing list if that exists as well (and that usually
does not work very well).

IOW: we need to be clear in what we want a platform for - and what not.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Jan Kiszka]

On 2017-11-21 18:11, Philippe Gerum wrote:
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.

Thanks for bringing this frankly on the table! For those who follow the
project, it's likely no news. So we were working on this issue also
internally, with users of Xenomai inside Siemens. And we have the
backing to enhance our involvement in upstream work. Right now we are
working on making this concrete.

There are many areas where contributions can be beneficial for the
project and its community, and many do not require deepest understanding
of the core, like around CI, test automation, distro packaging,
documentation, or user support. But some essential elements in my eyes are

 - building up a core team of kernel maintainers for Cobalt

 - offloading work from the shoulders of our extremely valuable
   maintainer

The second part will be achieved to a certain degree by the first one as
Philippe can probably confirm. So I would like to focus this and try to
make some first step:

We are currently planning a so far internal workshop with Philippe in
order to discuss how to bring more of our people but also others on
board regarding kernel maintenance topics. Topics to discussed are likely

 - current design and how to introduce people to it (tough, yeah...)
 - possible workflows and integration paths
 - update strategy and frequency
 - testing needs and strategies
 - supportable architectures
 - state and details of the new pipeline design
 - planning of and migration path to the new design

If there is interest in joining such a discussion, physically (will
likely take place in our office in Munich, Germany) or virtually
(provided time zones work out), please let us know. Time frame is more
likely early next year than mid of this December. And this shall be only
the kickoff for further discussions in the community!

Jan

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/22/2017 11:06 AM, Norbert Lange wrote:
> Hi,
> 
> not really happy to hear that, but this was already my impression.
> There is alot of knowledge of kernel, hardware and bootloader
> knowledge necessary to be able to maintain the ipipe patch, as
> newcomer to most of these I am just helpless. Unless someone is
> dedicated to that,
> there is not chance to keep up.
> 
> What you could do is to automate as much as possible, saving some of
> the regular grinding work.
> The way realtime is used with minimal configurations, FTB errors will
> show up late,
> and changes in kernel APIs are only carried over in actively used drivers.
> 
> ie.
> -   automated builds with several kernel configs

Agreed. We used to have that, until last year. We need this back.

> -   potential some tests under qemu with the above.
> 
> Buildroot does something similar, and this is very low maintenance
> cost once its setup,
> could automatically report issues or non-working config-switches.

Do you mean buildroot-CI?

> Nowadays you can let providers like Gitlab take care of keeping the
> servers running,
> as I understand it you have no limits to build-time unless the project
> is private.
> You get some good issue tracking on top of it, patches can be
> automatically checked in form of merge-requests.
> (In the unlikely case they go bust or get unfriendly, you can still
> tun an older Gitlab version on your own server)
> 
> 
> I really don`t see the advantage in separating the subprojects,
> its already complicated enough to piece everything together,
> and with automated builds you could atleast catch build-errors or fails-to-boot.
> I take unmaintained, but buildable code in-tree over unmaintained code
> in a separate project everyday.

Moving to Gitlab is definitely an option on the table.

> 
> Publicity
> 
> Dont know how to takle this, but its very easy to get a full IDE and
> start programming some embedded CPUs.
> Commercial OSes have a huge advantage there, cause it doesnt take much
> to get example code running (youre only going to hit walls as your
> problems get bigger than their ecosystem). First impressions count,
> and being able to debug through code gets you firsthand knowledge
> faster than any other approach.
> 
> In that respect some known-to-work hardware with known-to-work
> dual-kernel with a pre-setup dev environment would go a long way to
> ease the first steps and might gather some new interested users.
> Some cheap, high-volume, jtag-debugable SBC would do.
> 
> Otherwise theres some architecture-, bios- and ever changing
> kernel-magic involved just to get a plain system running.

Agreed, the idea of, e.g. a live image booting Xenomai to lower the
barrier on entry is a nice way to attract new users. This said, the
discussion I would like to see first is about fixing the existing issues
in the development and maintenance processes so that current users have
their investment in Xenomai kept safe.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/21/2017 08:54 PM, Dmitriy Cherkasov wrote:
> On 11/21/2017 09:11 AM, Philippe Gerum wrote:
> 
>> So, let's talk about the elephant in the room: the current situation of
>> the Xenomai project is not viable in the long run. I can only encourage
>> people who feel concerned about it to discuss openly the practical steps
>> to best address this challenge.
> 
> Hi Philippe,
> 
> I would be happy to help any way that I can, especially with any of the
> new pipeline work.
> 
We may want to discuss this in a separate thread if interested, however
some context may fit here:

linux-steely (master branch) as visible on the git server contains the
current state of this work, tracking the mainline tip as closely as
possible (up to commit #83bfd83650cc, anything on top is a new co-kernel
derived from Cobalt I'm toying with for experimenting with the pipeline
and new ideas for a better integration in Linux).

The development took place on imx6qp and imx7d so far; I want to port
this to aarch64 and started to do so. imx can run the basic tests, the
aarch64 port does not boot yet. The whole thing is still very much in a
state of flux, as better ways to make dual kernel support a basic Linux
feature - instead of a set of unrelated sideways - appear.

A reasonable plan would be to interface Xenomai's Cobalt core with the
new pipeline at some point, while keeping the I-pipe option available,
gradually phasing out the current I-pipe generation as the new one matures.

> Having said that, I think this is a good discussion to have. If there
> are commercial or institutional users of any of the somewhat neglected
> subsystems, this would be a good time to remind them to invest some
> resources into maintaining these things in the upstream project.
> 

Feedback and proposals for even simple changes which may help users in
the future are valuable contributions too, which come at virtually no
cost. Once a problem is stated, resources to fix it may be looked for.

> I think in general, hobbyist contributors will mostly work on what they
> find interesting to themselves, and if there is no hobbyist or
> commercial support for certain features then perhaps it does make sense
> to drop them.
> 
Ack. At any rate, shipping bit rot software people would unfortunately
rely upon never helped anyone.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

Hi Kendall,

On 11/21/2017 08:27 PM, Auel, Kendall wrote:
> Hi Philippe,
> 
> Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.
> 
> I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.
> 
We don't have that unfortunately. As suggested by several posters,
moving to a git-based, integrated development framework such as gitlab
or github would bring in that feature, and others we need too (CI).

I have no issue moving the project from the current git server at
xenomai.org to any of these environments.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

On 11/21/2017 06:26 PM, Greg Gallagher wrote:
> Hi,
>    I've been using Xenomai for a couple of years now and having been
> preparing my first patch.
> I'd love to help any way that is needed.  Documentation may be a good place
> for me to start.

There is no shortage of work on the documentation side. This would
definitely help a lot, thanks. To this end, it would be helpful if
people shared their experience about the most obvious issues they faced
with the existing documentation when discovering Xenomai.

>  I'd also
> be more than happy to help maintain some of the I/O frameworks.  I would
> probably need a mentor
> for guidance at the beginning.
> 

I'm willing to help anyone willing to contribute.

-- 
Philippe.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

    I really like the idea of having some TODO files, this would given new
comers to the project a place to start.
Improving the documentation and adding a quick start guide might help get
more people interested in using
Xenomai.  With more users hopefully that would lead to more contributors
and not just more feature requests.

    To increase the presence of Xenomai would it make sense to have some
people focus on drivers and
maintenance for some popular community boards?  I personally focus on the
Xilinx Zynq platform,
but it might be useful to have people build and test images for  raspberry
pi boards, beaglebones and other
popular maker boards for every stable release of Xenomai.  I've posted my
steps on how to build Xenomai
for Zynq and will start to build and maintain pre-built binaries for Zynq
and run tests for the boards I have access to.
I find a lot of people that give me feedback on the Xenomai on Zynq seem to
just want to get started quickly
and go.  This really only addresses increasing Xenomai presence and would
increase the total work which
might not be what's desired right now.


On Wed, Nov 22, 2017 at 7:33 AM, Leopold Palomo-Avellaneda <leo@alaxarxa.net
> wrote:

> Hi,
>
> yes, it's true. We have an Elmer and his cousin Wilbur is rear the door.
>
> Let me remark some points of your great email:
>
> - about the I/O frameworks
>
> On 21/11/17 18:11, Philippe Gerum wrote:
> > The
> > situation has reached a point where I see no alternative to dropping
> > them if the situation does not improve, ...
>
> - about your rule in the project:
>
> > I have not been scaling to the Xenomai
> > maintenance, development and documentation tasks, with the requirement
> > of running my business in parallel.
>
> - about how to solve it:
>
> > The solution to this serious problem is fitting the project to the
> > available resources by narrowing its goal, or conversely, by growing the
> > pool of contributors.
>
> - about the presence of Xenomai in the world:
>
> > to my current knowledge,
> > Xenomai is present in a broad range of applications and systems:
> > magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> > communication equipment, autonomous vehicles, control & automation
> > systems in various plants.
>
> - about where we came from:
>
> > On the sad side of the story, this project has virtually become a
> > one-man show the day Gilles - my long-time friend and hacking soul mate
> > - left us. That show is too big for me to run it alone ...
>
>
> And finally, if you let me talk about our Elmer.
>
> The I/O frameworks are IMHO are crucial. It has a very limited scenario to
> develop a RT system if it has no interaction with the external devices, or
> whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
> continuing contributing to the project. Also, I have seen that new people
> have
> interest.
>
> But I would like to ask you directly Philippe some practical steps that
> could
> address to this challenge:
>
> - Would you be willing to move Xenomai to some platform like github, or
> similar?
> It will have some advantages like issues management, maintenance, (more
> visibility?), etc.
>
> - Would you be willing to delegate tasks of the project to other people,
> that
> maybe will not make it as good as you will do, like documentation, web
> site, or
> parts of code, but made then with an acceptable quality? And please, don't
> take
> bad, it's a difficult thing. I have to confess that for me, it's very
> difficult.
>
> - Would you be willing to guide new contributors and give them
> responsibilities
> of important parts of the code?
>
> - Would you be willing to have the role as coordinator and leader of the
> project
> changing from one man show to some more open project? will be it possible?
> I
> don't know if because license issues or whatever would let it...
>
> - Would you be willing to change the build system from autotools to another
> modern tool? (Ex CMake?) IMHO few people understand autotools and it's a
> barrier
> for the new contributors, at least in another opensource projects.
> However, I
> have to admit that the entry level in Xenomai is high, so, autotools
> should not
> be a problem.
>
> And yes, the lost of Gilles was a great blow, on a the personal level and
> for
> his contributions on the project.
>
> From my part, I can contribute if there's interest, in Debian (Ubuntu)
> packages.
> Also, in testing and trying to help in the RTnet part, as user that I'm.
> So, I
> could try to provide some preconfigured scenarios to the people that would
> like
> to entry in Xenomai.
>
> I have to admit that I'm a bit scared because we depend of Xenomai in some
> projects in my University. But, probably we could try to move to
> RT_PREMPT. But,
> because its history and my "affection" for the project I would prefer stay
> with
> it and try to help.
>
> Cheers,
>
> Leopold
>
> --
> --
> 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: 833 bytes
> Desc: OpenPGP digital signature
> URL: <http://xenomai.org/pipermail/xenomai/attachments/20171122/
> af6d7b02/attachment.sig>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Leopold Palomo-Avellaneda]

Hi,

yes, it's true. We have an Elmer and his cousin Wilbur is rear the door.

Let me remark some points of your great email:

- about the I/O frameworks

On 21/11/17 18:11, Philippe Gerum wrote:
> The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, ...

- about your rule in the project:

> I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.

- about how to solve it:

> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.

- about the presence of Xenomai in the world:

> to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.

- about where we came from:

> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone ...


And finally, if you let me talk about our Elmer.

The I/O frameworks are IMHO are crucial. It has a very limited scenario to
develop a RT system if it has no interaction with the external devices, or
whatever. I have the hope ("A new hope" ;-)) that Siemens and Denx guys,
continuing contributing to the project. Also, I have seen that new people have
interest.

But I would like to ask you directly Philippe some practical steps that could
address to this challenge:

- Would you be willing to move Xenomai to some platform like github, or similar?
It will have some advantages like issues management, maintenance, (more
visibility?), etc.

- Would you be willing to delegate tasks of the project to other people, that
maybe will not make it as good as you will do, like documentation, web site, or
parts of code, but made then with an acceptable quality? And please, don't take
bad, it's a difficult thing. I have to confess that for me, it's very difficult.

- Would you be willing to guide new contributors and give them responsibilities
of important parts of the code?

- Would you be willing to have the role as coordinator and leader of the project
changing from one man show to some more open project? will be it possible? I
don't know if because license issues or whatever would let it...

- Would you be willing to change the build system from autotools to another
modern tool? (Ex CMake?) IMHO few people understand autotools and it's a barrier
for the new contributors, at least in another opensource projects. However, I
have to admit that the entry level in Xenomai is high, so, autotools should not
be a problem.

And yes, the lost of Gilles was a great blow, on a the personal level and for
his contributions on the project.

From my part, I can contribute if there's interest, in Debian (Ubuntu) packages.
Also, in testing and trying to help in the RTnet part, as user that I'm. So, I
could try to provide some preconfigured scenarios to the people that would like
to entry in Xenomai.

I have to admit that I'm a bit scared because we depend of Xenomai in some
projects in my University. But, probably we could try to move to RT_PREMPT. But,
because its history and my "affection" for the project I would prefer stay with
it and try to help.

Cheers,

Leopold

-- 
--
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: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20171122/af6d7b02/attachment.sig>

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Norbert Lange]

Hi,

not really happy to hear that, but this was already my impression.
There is alot of knowledge of kernel, hardware and bootloader
knowledge necessary to be able to maintain the ipipe patch, as
newcomer to most of these I am just helpless. Unless someone is
dedicated to that,
there is not chance to keep up.

What you could do is to automate as much as possible, saving some of
the regular grinding work.
The way realtime is used with minimal configurations, FTB errors will
show up late,
and changes in kernel APIs are only carried over in actively used drivers.

ie.
-   automated builds with several kernel configs
-   potential some tests under qemu with the above.

Buildroot does something similar, and this is very low maintenance
cost once its setup,
could automatically report issues or non-working config-switches.
Nowadays you can let providers like Gitlab take care of keeping the
servers running,
as I understand it you have no limits to build-time unless the project
is private.
You get some good issue tracking on top of it, patches can be
automatically checked in form of merge-requests.
(In the unlikely case they go bust or get unfriendly, you can still
tun an older Gitlab version on your own server)


I really don`t see the advantage in separating the subprojects,
its already complicated enough to piece everything together,
and with automated builds you could atleast catch build-errors or fails-to-boot.
I take unmaintained, but buildable code in-tree over unmaintained code
in a separate project everyday.

Publicity

Dont know how to takle this, but its very easy to get a full IDE and
start programming some embedded CPUs.
Commercial OSes have a huge advantage there, cause it doesnt take much
to get example code running (youre only going to hit walls as your
problems get bigger than their ecosystem). First impressions count,
and being able to debug through code gets you firsthand knowledge
faster than any other approach.

In that respect some known-to-work hardware with known-to-work
dual-kernel with a pre-setup dev environment would go a long way to
ease the first steps and might gather some new interested users.
Some cheap, high-volume, jtag-debugable SBC would do.

Otherwise theres some architecture-, bios- and ever changing
kernel-magic involved just to get a plain system running.

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Dmitriy Cherkasov]

On 11/21/2017 09:11 AM, Philippe Gerum wrote:

> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.

Hi Philippe,

I would be happy to help any way that I can, especially with any of the new 
pipeline work.

Having said that, I think this is a good discussion to have. If there are 
commercial or institutional users of any of the somewhat neglected subsystems, 
this would be a good time to remind them to invest some resources into 
maintaining these things in the upstream project.

I think in general, hobbyist contributors will mostly work on what they find 
interesting to themselves, and if there is no hobbyist or commercial support for 
certain features then perhaps it does make sense to drop them.

-Dmitriy

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Auel, Kendall]

Hi Philippe,

Is there an online bug tracking and feature request database? This would be a useful way to distribute work and to sync up contributors. I think the kernel uses Bugzilla, and Ubuntu has Launchpad. No doubt there are many others.

I'd like to contribute in some way. I've been having a lot of fun as a Xenomai user.

Regards,
Kendall


-----Original Message-----
From: Xenomai [mailto:xenomai-bounces@xenomai.org] On Behalf Of Philippe Gerum
Sent: Tuesday, November 21, 2017 9:12 AM
To: Xenomai@xenomai.org
Subject: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room


As the GIT commit history shows, there has been no sustained effort in maintaining several of the Xenomai I/O frameworks for several months (e.g. RTnet, analogy), even years in some cases, despite obvious bugs are still haunting the code base according to the mailing list. The situation has reached a point where I see no alternative to dropping them if the situation does not improve, because there is absolutely no point in this project shipping bit rot software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since Gilles passed away last year, I have not been scaling to the Xenomai maintenance, development and documentation tasks, with the requirement of running my business in parallel.

The solution to this serious problem is fitting the project to the available resources by narrowing its goal, or conversely, by growing the pool of contributors.

In addition, we can rework the most tricky part of the implementation to make it simpler to maintain, better documented, drastically lowering the barrier on entry for new contributors, which is what I've been working on for a year with the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again limited by the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of contributions from only a few committed people and companies. At this chance, let's mention that people who have been deploying Xenomai in industrial applications owe a lot to Wolfgang Denk from Denx Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported the project in crucial ways directly or indirectly over the years, and still do.

Xenomai as a dual kernel technology showcase has been quietly delivering on the promise of real-time Linux for more than a decade now, with marketing tools limited to showing decent code quality, good and reliable performance figures. As a result, to my current knowledge, Xenomai is present in a broad range of applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning, communication equipment, autonomous vehicles, control & automation systems in various plants.

On the sad side of the story, this project has virtually become a one-man show the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and stalled two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of the Xenomai project is not viable in the long run. I can only encourage people who feel concerned about it to discuss openly the practical steps to best address this challenge.

Thanks,

--
Philippe.

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Greg Gallagher]

Hi,
   I've been using Xenomai for a couple of years now and having been
preparing my first patch.
I'd love to help any way that is needed.  Documentation may be a good place
for me to start.  I'd also
be more than happy to help maintain some of the I/O frameworks.  I would
probably need a mentor
for guidance at the beginning.

Thanks

On Tue, Nov 21, 2017 at 12:11 PM, Philippe Gerum <rpm@xenomai.org> wrote:

>
> As the GIT commit history shows, there has been no sustained effort in
> maintaining several of the Xenomai I/O frameworks for several months
> (e.g. RTnet, analogy), even years in some cases, despite obvious bugs
> are still haunting the code base according to the mailing list. The
> situation has reached a point where I see no alternative to dropping
> them if the situation does not improve, because there is absolutely no
> point in this project shipping bit rot software that won't ever be fixed.
>
> Unfortunately, this is only the tip of the iceberg. Let's face it, since
> Gilles passed away last year, I have not been scaling to the Xenomai
> maintenance, development and documentation tasks, with the requirement
> of running my business in parallel.
>
> The solution to this serious problem is fitting the project to the
> available resources by narrowing its goal, or conversely, by growing the
> pool of contributors.
>
> In addition, we can rework the most tricky part of the implementation to
> make it simpler to maintain, better documented, drastically lowering the
> barrier on entry for new contributors, which is what I've been working
> on for a year with the 4th generation of the interrupt pipeline.
> Progress on this front has been significant already, but once again
> limited by the time I have been able to devote to this development so far.
>
> For the past 16 years, this project has lived on various types of
> contributions from only a few committed people and companies. At this
> chance, let's mention that people who have been deploying Xenomai in
> industrial applications owe a lot to Wolfgang Denk from Denx
> Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
> the project in crucial ways directly or indirectly over the years, and
> still do.
>
> Xenomai as a dual kernel technology showcase has been quietly delivering
> on the promise of real-time Linux for more than a decade now, with
> marketing tools limited to showing decent code quality, good and
> reliable performance figures. As a result, to my current knowledge,
> Xenomai is present in a broad range of applications and systems:
> magnetic resonance scanners, 2D/3D printers, navigation & positioning,
> communication equipment, autonomous vehicles, control & automation
> systems in various plants.
>
> On the sad side of the story, this project has virtually become a
> one-man show the day Gilles - my long-time friend and hacking soul mate
> - left us. That show is too big for me to run it alone, which entails
> maintaining:
>
> - the interrupt pipeline for 7 CPU architectures
> - the Cobalt co-kernel
> - 4 APIs, plus the "copperplate" mediating layer
> - several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI,
> GPIO
> - the documentation (which is currently unfriendly to newcomers, and
> stalled two years ago or so)
> - the website
> - the testing and release processes
>
> So, let's talk about the elephant in the room: the current situation of
> the Xenomai project is not viable in the long run. I can only encourage
> people who feel concerned about it to discuss openly the practical steps
> to best address this challenge.
>
> Thanks,
>
> --
> Philippe.
>
> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai
>

[Xenomai] [RFC] RTnet, Analogy and the elephant in the room

[Philippe Gerum]

As the GIT commit history shows, there has been no sustained effort in
maintaining several of the Xenomai I/O frameworks for several months
(e.g. RTnet, analogy), even years in some cases, despite obvious bugs
are still haunting the code base according to the mailing list. The
situation has reached a point where I see no alternative to dropping
them if the situation does not improve, because there is absolutely no
point in this project shipping bit rot software that won't ever be fixed.

Unfortunately, this is only the tip of the iceberg. Let's face it, since
Gilles passed away last year, I have not been scaling to the Xenomai
maintenance, development and documentation tasks, with the requirement
of running my business in parallel.

The solution to this serious problem is fitting the project to the
available resources by narrowing its goal, or conversely, by growing the
pool of contributors.

In addition, we can rework the most tricky part of the implementation to
make it simpler to maintain, better documented, drastically lowering the
barrier on entry for new contributors, which is what I've been working
on for a year with the 4th generation of the interrupt pipeline.
Progress on this front has been significant already, but once again
limited by the time I have been able to devote to this development so far.

For the past 16 years, this project has lived on various types of
contributions from only a few committed people and companies. At this
chance, let's mention that people who have been deploying Xenomai in
industrial applications owe a lot to Wolfgang Denk from Denx
Engineering, Siemens's Jan Kiszka and Jorge Ramirez, who have supported
the project in crucial ways directly or indirectly over the years, and
still do.

Xenomai as a dual kernel technology showcase has been quietly delivering
on the promise of real-time Linux for more than a decade now, with
marketing tools limited to showing decent code quality, good and
reliable performance figures. As a result, to my current knowledge,
Xenomai is present in a broad range of applications and systems:
magnetic resonance scanners, 2D/3D printers, navigation & positioning,
communication equipment, autonomous vehicles, control & automation
systems in various plants.

On the sad side of the story, this project has virtually become a
one-man show the day Gilles - my long-time friend and hacking soul mate
- left us. That show is too big for me to run it alone, which entails
maintaining:

- the interrupt pipeline for 7 CPU architectures
- the Cobalt co-kernel
- 4 APIs, plus the "copperplate" mediating layer
- several real-time I/O frameworks, including CAN, RTnet, Analogy, SPI, GPIO
- the documentation (which is currently unfriendly to newcomers, and
stalled two years ago or so)
- the website
- the testing and release processes

So, let's talk about the elephant in the room: the current situation of
the Xenomai project is not viable in the long run. I can only encourage
people who feel concerned about it to discuss openly the practical steps
to best address this challenge.

Thanks,

-- 
Philippe.