[Buildroot] Xenomai 3.x

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi !

I am trying to get a working Xenomai 3.x package with buildroot.
My main objective is to have it running with Mercury (ie. PREEMPT_RT
and not Adeos), and ideally with the compatibility layer for Xenomai
2.x existing applications.

I had a look at this thread :
http://lists.busybox.net/pipermail/buildroot/2016-January/150791.html

I was wondering if anyone already worked on this stuff, in order to
combine the efforts ?
I can do it on my own, of course, but I think it would be better to
have it integrated upstream :) !

Thanks,
JM

[Buildroot] Xenomai 3.x

[jerry at chordia.co.uk]

Hello Jean-Michel

> Subject: Xenomai 3.x
> 
> Hi !
> 
> I am trying to get a working Xenomai 3.x package with buildroot.
> My main objective is to have it running with Mercury (ie. PREEMPT_RT and
> not Adeos), and ideally with the compatibility layer for Xenomai 2.x existing
> applications.
> 

I'm afraid I ran out of time on that one and had to settle for PREMPT_RT alone. 

Please keep me posted if you progress this as I may be able to devote time to it later this year.

BR,

Jerry.
 

[Buildroot] Xenomai 3.x

[Thomas Petazzoni]

Hello,

On Wed, 5 Oct 2016 09:07:28 +0200, Jean-Michel Hautbois wrote:

> I am trying to get a working Xenomai 3.x package with buildroot.
> My main objective is to have it running with Mercury (ie. PREEMPT_RT
> and not Adeos), and ideally with the compatibility layer for Xenomai
> 2.x existing applications.
> 
> I had a look at this thread :
> http://lists.busybox.net/pipermail/buildroot/2016-January/150791.html
> 
> I was wondering if anyone already worked on this stuff, in order to
> combine the efforts ?
> I can do it on my own, of course, but I think it would be better to
> have it integrated upstream :) !

So far, we haven't received any patch to add Xenomai 3.x support in
Buildroot, and I've not heard (besides you asking questions on IRC)
anyone working on this currently.

So patches are definitely welcome. It's not clear to me whether we want
to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
3.x is sufficient, as a replacement for Xeonmai 2.x.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi Thomas,

2016-10-05 9:55 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Wed, 5 Oct 2016 09:07:28 +0200, Jean-Michel Hautbois wrote:
>
>> I am trying to get a working Xenomai 3.x package with buildroot.
>> My main objective is to have it running with Mercury (ie. PREEMPT_RT
>> and not Adeos), and ideally with the compatibility layer for Xenomai
>> 2.x existing applications.
>>
>> I had a look at this thread :
>> http://lists.busybox.net/pipermail/buildroot/2016-January/150791.html
>>
>> I was wondering if anyone already worked on this stuff, in order to
>> combine the efforts ?
>> I can do it on my own, of course, but I think it would be better to
>> have it integrated upstream :) !
>
> So far, we haven't received any patch to add Xenomai 3.x support in
> Buildroot, and I've not heard (besides you asking questions on IRC)
> anyone working on this currently.
>
> So patches are definitely welcome. It's not clear to me whether we want
> to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
> 3.x is sufficient, as a replacement for Xeonmai 2.x.

Well, yes, it is not clear for me either.
I am not sure that it has to be compiled the same way.
Well, if I have anything I can show, I will ask for advices.

Thanks,
JM

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi Jerry,

2016-10-05 9:54 GMT+02:00  <jerry@chordia.co.uk>:
> Hello Jean-Michel
>
>> Subject: Xenomai 3.x
>>
>> Hi !
>>
>> I am trying to get a working Xenomai 3.x package with buildroot.
>> My main objective is to have it running with Mercury (ie. PREEMPT_RT and
>> not Adeos), and ideally with the compatibility layer for Xenomai 2.x existing
>> applications.
>>
>
> I'm afraid I ran out of time on that one and had to settle for PREMPT_RT alone.

What do you mean exactly, did you install a PREEMPT_RT kernel and have
a Xenomai 3.x on your side or no Xenomai at all, due to a lack of time
?

Thanks
JM

[Buildroot] Xenomai 3.x

[jerry at chordia.co.uk]

Hi JM

> 
> What do you mean exactly, did you install a PREEMPT_RT kernel and have a
> Xenomai 3.x on your side or no Xenomai at all, due to a lack of time ?

We ended up working with the PREEMPT_RT patch on its own. Adding Xenomai started to look like a project all of its own.
 
> Thanks
> JM

You are welcome. 

May I ask about your project? Have you got something that already uses Xenomai or is the interest in RT Linux more generally?

BR

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi,

2016-10-05 12:05 GMT+02:00  <jerry@chordia.co.uk>:
> Hi JM
>
>>
>> What do you mean exactly, did you install a PREEMPT_RT kernel and have a
>> Xenomai 3.x on your side or no Xenomai at all, due to a lack of time ?
>
> We ended up working with the PREEMPT_RT patch on its own. Adding Xenomai started to look like a project all of its own.

OK.

> You are welcome.
>
> May I ask about your project? Have you got something that already uses Xenomai or is the interest in RT Linux more generally?

It is an existing product chich runs Xenomai 2.6 and I am upgrading to
Xenomai 3.
The objective is to make it work with PREEMPT_RT, as it eases the
choice of kernel (with Cobalt, you need to have a kernel supported by
Xenomai, and last one is 4.1 now. Or you can try to get it working
with the latest kernel but, not that easy :)).

Right now, I am still hesitating, as I can have one xenomai.mk file
which would be pretty much the same for Cobalt, but needs some
modifications for Mercury. And you get a lot of ifeq() statements
which is not nice.
Or, having one xenomai-2.mk and one xenomai-3.mk (or anything similar).
Or, having one xenomai.mk which would support Xenomai 2.x and Xenomai
3.x Cobalt only, and one xenomai-mercury.mk which would add support
for mercury options.

Not that easy to choose :).
JM

[Buildroot] Xenomai 3.x

[Thomas Petazzoni]

Hello,

On Wed, 5 Oct 2016 14:41:08 +0200, Jean-Michel Hautbois wrote:

> Right now, I am still hesitating, as I can have one xenomai.mk file
> which would be pretty much the same for Cobalt, but needs some
> modifications for Mercury. And you get a lot of ifeq() statements
> which is not nice.
> Or, having one xenomai-2.mk and one xenomai-3.mk (or anything similar).
> Or, having one xenomai.mk which would support Xenomai 2.x and Xenomai
> 3.x Cobalt only, and one xenomai-mercury.mk which would add support
> for mercury options.

For now, I think you should just start with a package/xenomai3/ package
that handles all aspects of Xenomai 3 (i.e Cobalt and Mercury). Once
you have something working, we can see what it looks like, and discuss
whether merging with xenomai.mk is appropriate or not.

What do you think about such an approach?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi Thomas,

2016-10-05 14:56 GMT+02:00 Thomas Petazzoni
<thomas.petazzoni@free-electrons.com>:
> Hello,
>
> On Wed, 5 Oct 2016 14:41:08 +0200, Jean-Michel Hautbois wrote:
>
>> Right now, I am still hesitating, as I can have one xenomai.mk file
>> which would be pretty much the same for Cobalt, but needs some
>> modifications for Mercury. And you get a lot of ifeq() statements
>> which is not nice.
>> Or, having one xenomai-2.mk and one xenomai-3.mk (or anything similar).
>> Or, having one xenomai.mk which would support Xenomai 2.x and Xenomai
>> 3.x Cobalt only, and one xenomai-mercury.mk which would add support
>> for mercury options.
>
> For now, I think you should just start with a package/xenomai3/ package
> that handles all aspects of Xenomai 3 (i.e Cobalt and Mercury). Once
> you have something working, we can see what it looks like, and discuss
> whether merging with xenomai.mk is appropriate or not.
>
> What do you think about such an approach?

Sounds good.
See you in Berlin :) !

JM

[Buildroot] Xenomai 3.x

[Arnout Vandecappelle]

On 05-10-16 10:30, Jean-Michel Hautbois wrote:
> Hi Thomas,
> 
> 2016-10-05 9:55 GMT+02:00 Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com>:
>> Hello,
>>
>> On Wed, 5 Oct 2016 09:07:28 +0200, Jean-Michel Hautbois wrote:
>>
>>> I am trying to get a working Xenomai 3.x package with buildroot.
>>> My main objective is to have it running with Mercury (ie. PREEMPT_RT
>>> and not Adeos), and ideally with the compatibility layer for Xenomai
>>> 2.x existing applications.
>>>
>>> I had a look at this thread :
>>> http://lists.busybox.net/pipermail/buildroot/2016-January/150791.html
>>>
>>> I was wondering if anyone already worked on this stuff, in order to
>>> combine the efforts ?
>>> I can do it on my own, of course, but I think it would be better to
>>> have it integrated upstream :) !
>>
>> So far, we haven't received any patch to add Xenomai 3.x support in
>> Buildroot, and I've not heard (besides you asking questions on IRC)
>> anyone working on this currently.
>>
>> So patches are definitely welcome. It's not clear to me whether we want
>> to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
>> 3.x is sufficient, as a replacement for Xeonmai 2.x.
> 
> Well, yes, it is not clear for me either.
> I am not sure that it has to be compiled the same way.
> Well, if I have anything I can show, I will ask for advices.

 AFAIK the Xenomai 3 API should be fully backward compatible with Xenomai 2, so
I see no reason to support both. I'd just "bump" Xenomai.

 A first patch would do a bump with just Cobalt, which is more or less what we
have now. A second patch would add the option to use Mercury instead of Cobalt.

 This is also the feedback I gave in the thread that you refer to.

 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

Hi Arnout,

Le 6 oct. 2016 00:54, "Arnout Vandecappelle" <arnout@mind.be> a ?crit :
>
>
>
> On 05-10-16 10:30, Jean-Michel Hautbois wrote:
> > Hi Thomas,
> >
> > 2016-10-05 9:55 GMT+02:00 Thomas Petazzoni
> > <thomas.petazzoni@free-electrons.com>:
> >> Hello,
> >>
> >> On Wed, 5 Oct 2016 09:07:28 +0200, Jean-Michel Hautbois wrote:
> >>
> >>> I am trying to get a working Xenomai 3.x package with buildroot.
> >>> My main objective is to have it running with Mercury (ie. PREEMPT_RT
> >>> and not Adeos), and ideally with the compatibility layer for Xenomai
> >>> 2.x existing applications.
> >>>
> >>> I had a look at this thread :
> >>> http://lists.busybox.net/pipermail/buildroot/2016-January/150791.html
> >>>
> >>> I was wondering if anyone already worked on this stuff, in order to
> >>> combine the efforts ?
> >>> I can do it on my own, of course, but I think it would be better to
> >>> have it integrated upstream :) !
> >>
> >> So far, we haven't received any patch to add Xenomai 3.x support in
> >> Buildroot, and I've not heard (besides you asking questions on IRC)
> >> anyone working on this currently.
> >>
> >> So patches are definitely welcome. It's not clear to me whether we want
> >> to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
> >> 3.x is sufficient, as a replacement for Xeonmai 2.x.
> >
> > Well, yes, it is not clear for me either.
> > I am not sure that it has to be compiled the same way.
> > Well, if I have anything I can show, I will ask for advices.
>
>  AFAIK the Xenomai 3 API should be fully backward compatible with Xenomai
2, so
> I see no reason to support both. I'd just "bump" Xenomai.

Well I am not so sure about that, there is a complete migration guide and
some applications may need some modifications to work correctly with
Xenomai 3. And there is another reason I would not bump to 3.x instead of
making a different package : some people may want to stay on the 2.6 branch
(which is now 2.6.5) which is a EOL tree but still, some people may not
want to bump to 3.x as they may have a lot of their system depending on
Xenomai 2.6.

>  A first patch would do a bump with just Cobalt, which is more or less
what we
> have now. A second patch would add the option to use Mercury instead of
Cobalt.
>
>  This is also the feedback I gave in the thread that you refer to.

Yes and I started to work on this way, but I don't like having too much
ifeq() in the source code, blame me :-).

I am open to all suggestions but please note I will not test Cobalt as I
don't have a kernel to do so (and no time for it) so the patch proposal
will be a RFC for starting.

Thanks,
JM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20161006/0ef97598/attachment.html>

[Buildroot] Xenomai 3.x

[Arnout Vandecappelle]

 Thomas, Peter, do you agree with what I write below?


On 06-10-16 07:34, Jean-Michel Hautbois wrote:
> Hi Arnout,
> 
> Le 6 oct. 2016 00:54, "Arnout Vandecappelle" <arnout@mind.be
> <mailto:arnout@mind.be>> a ?crit :
>>
>>
>>
>> On 05-10-16 10:30, Jean-Michel Hautbois wrote:
>> > Hi Thomas,
>> >
>> > 2016-10-05 9:55 GMT+02:00 Thomas Petazzoni
>> > <thomas.petazzoni@free-electrons.com
> <mailto:thomas.petazzoni@free-electrons.com>>:
[snip]

>> >> So patches are definitely welcome. It's not clear to me whether we want
>> >> to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
>> >> 3.x is sufficient, as a replacement for Xeonmai 2.x.
>> >
>> > Well, yes, it is not clear for me either.
>> > I am not sure that it has to be compiled the same way.
>> > Well, if I have anything I can show, I will ask for advices.
>>
>>  AFAIK the Xenomai 3 API should be fully backward compatible with Xenomai 2, so
>> I see no reason to support both. I'd just "bump" Xenomai.
> 
> Well I am not so sure about that, there is a complete migration guide and some
> applications may need some modifications to work correctly with Xenomai 3. And
> there is another reason I would not bump to 3.x instead of making a different
> package : some people may want to stay on the 2.6 branch (which is now 2.6.5)
> which is a EOL tree but still, some people may not want to bump to 3.x as they
> may have a lot of their system depending on Xenomai 2.6.

 For most packages (libraries), we do bumps even if there are API changes. But
admittedly most libraries are not user-facing, i.e. they are only used by other
packages in buildroot and not by user application code.

 We want to limit the number of versioned packages to ease maintenance burden.
And we certainly don't want to carry versions that have no upstream support
(although again, there are exceptions to this rule).

 I have taken a quick look to the migration guide. To me it seems that many
applications will not need any migration at all, and some applications will
require some names to be changed in their code. Unfortunately in some cases it
can be somewhat tricky to find out what things have been renamed, e.g. the
/proc/xenomai files are just strings in your scripts so no compile time errors.

 So for many users, it is actually easier if it's a simple version bump.
Introducing a new xenomai3 package would make their life more difficult since
they have to update their Buildroot configuration to make the switch. Obviously
that

 So this is slightly borderline. Since upstream Xenomai 2 gets no "stable
updates", I tend to prefer to remove it.


>>  A first patch would do a bump with just Cobalt, which is more or less what we
>> have now. A second patch would add the option to use Mercury instead of Cobalt.
>>
>>  This is also the feedback I gave in the thread that you refer to.
> 
> Yes and I started to work on this way, but I don't like having too much ifeq()
> in the source code, blame me :-).

 I guess the ifeqs are needed for the Mercury vs Cobalt support, no? For this, I
agree that it would make sense to make a separate xenomai-mercury package (and
keep the xenomai package as Cobalt only).


> I am open to all suggestions but please note I will not test Cobalt as I don't
> have a kernel to do so (and no time for it) so the patch proposal will be a RFC
> for starting.

 In that case, to make your life easier, you may want to just create a
xenomai-mercury package and leave the xenomai package alone. Someone else can
pick up the xenomai3 Cobalt support later.


 Regards,
 Arnout

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] Xenomai 3.x

[Jean-Michel Hautbois]

2016-10-06 11:01 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:
>  Thomas, Peter, do you agree with what I write below?
>
>
> On 06-10-16 07:34, Jean-Michel Hautbois wrote:
>> Hi Arnout,
>>
>> Le 6 oct. 2016 00:54, "Arnout Vandecappelle" <arnout@mind.be
>> <mailto:arnout@mind.be>> a ?crit :
>>>
>>>
>>>
>>> On 05-10-16 10:30, Jean-Michel Hautbois wrote:
>>> > Hi Thomas,
>>> >
>>> > 2016-10-05 9:55 GMT+02:00 Thomas Petazzoni
>>> > <thomas.petazzoni@free-electrons.com
>> <mailto:thomas.petazzoni@free-electrons.com>>:
> [snip]
>
>>> >> So patches are definitely welcome. It's not clear to me whether we want
>>> >> to support both Xenomai 2.x and Xenomai 3.x, or if supporting Xenomai
>>> >> 3.x is sufficient, as a replacement for Xeonmai 2.x.
>>> >
>>> > Well, yes, it is not clear for me either.
>>> > I am not sure that it has to be compiled the same way.
>>> > Well, if I have anything I can show, I will ask for advices.
>>>
>>>  AFAIK the Xenomai 3 API should be fully backward compatible with Xenomai 2, so
>>> I see no reason to support both. I'd just "bump" Xenomai.
>>
>> Well I am not so sure about that, there is a complete migration guide and some
>> applications may need some modifications to work correctly with Xenomai 3. And
>> there is another reason I would not bump to 3.x instead of making a different
>> package : some people may want to stay on the 2.6 branch (which is now 2.6.5)
>> which is a EOL tree but still, some people may not want to bump to 3.x as they
>> may have a lot of their system depending on Xenomai 2.6.
>
>  For most packages (libraries), we do bumps even if there are API changes. But
> admittedly most libraries are not user-facing, i.e. they are only used by other
> packages in buildroot and not by user application code.
>
>  We want to limit the number of versioned packages to ease maintenance burden.
> And we certainly don't want to carry versions that have no upstream support
> (although again, there are exceptions to this rule).
>
>  I have taken a quick look to the migration guide. To me it seems that many
> applications will not need any migration at all, and some applications will
> require some names to be changed in their code. Unfortunately in some cases it
> can be somewhat tricky to find out what things have been renamed, e.g. the
> /proc/xenomai files are just strings in your scripts so no compile time errors.
>
>  So for many users, it is actually easier if it's a simple version bump.
> Introducing a new xenomai3 package would make their life more difficult since
> they have to update their Buildroot configuration to make the switch. Obviously
> that
>
>  So this is slightly borderline. Since upstream Xenomai 2 gets no "stable
> updates", I tend to prefer to remove it.
>

OK, I agree with you.

>>>  A first patch would do a bump with just Cobalt, which is more or less what we
>>> have now. A second patch would add the option to use Mercury instead of Cobalt.
>>>
>>>  This is also the feedback I gave in the thread that you refer to.
>>
>> Yes and I started to work on this way, but I don't like having too much ifeq()
>> in the source code, blame me :-).
>
>  I guess the ifeqs are needed for the Mercury vs Cobalt support, no? For this, I
> agree that it would make sense to make a separate xenomai-mercury package (and
> keep the xenomai package as Cobalt only).
>
>
>> I am open to all suggestions but please note I will not test Cobalt as I don't
>> have a kernel to do so (and no time for it) so the patch proposal will be a RFC
>> for starting.
>
>  In that case, to make your life easier, you may want to just create a
> xenomai-mercury package and leave the xenomai package alone. Someone else can
> pick up the xenomai3 Cobalt support later.

OK, I think it is a good idea.

Thanks,
JM

[Buildroot] Xenomai 3.x

[Thomas Petazzoni]

Hello,

On Thu, 6 Oct 2016 11:01:33 +0200, Arnout Vandecappelle wrote:

>  We want to limit the number of versioned packages to ease maintenance burden.
> And we certainly don't want to carry versions that have no upstream support
> (although again, there are exceptions to this rule).
> 
>  I have taken a quick look to the migration guide. To me it seems that many
> applications will not need any migration at all, and some applications will
> require some names to be changed in their code. Unfortunately in some cases it
> can be somewhat tricky to find out what things have been renamed, e.g. the
> /proc/xenomai files are just strings in your scripts so no compile time errors.
> 
>  So for many users, it is actually easier if it's a simple version bump.
> Introducing a new xenomai3 package would make their life more difficult since
> they have to update their Buildroot configuration to make the switch. Obviously
> that
> 
>  So this is slightly borderline. Since upstream Xenomai 2 gets no "stable
> updates", I tend to prefer to remove it.

Fine with me.

> > Yes and I started to work on this way, but I don't like having too much ifeq()
> > in the source code, blame me :-).  
> 
>  I guess the ifeqs are needed for the Mercury vs Cobalt support, no? For this, I
> agree that it would make sense to make a separate xenomai-mercury package (and
> keep the xenomai package as Cobalt only).

For this, I am not so sure. I dislike when we have multiple packages
that fetch the same source code. We do have this in a few places, but
it's not something that is really great, so I'd prefer to avoid it when
possible. So I'd prefer to have a single Xenomai package that handles
both the Mercury and Cobalt cases.

But of course, we can only judge once we see the actual patches.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com