[Buildroot] [PATCH 0/1] xenomai: Add choice for Cobalt/Mercury core

[Buildroot] [PATCH 0/1] xenomai: Add choice for Cobalt/Mercury core

[Pawel Sikora]

Maybe this is not completely an 'choice' option, because it depends
on enabled/disabled option for Linux Kernel extentions and 
this will be always just one option in each configuration...

But choice menu is quite readable in this case so that's why I used it.

I've been thinking first to let the user decide to have Mercury
or Cobalt even if one would have I-Pipe patch for the Linux Kernel,
but then, what is the purpose of using Mercury if you have patched Kernel?

If we would like to let users decide anyway, then form of the patch will
change and most probably the 'choice' style will be dropped because it's
not possible to select option in 'choice' menu from some other config?

Let me know what do you think about this approach and if you have any comments.

Regards,
Pawel

Pawel Sikora (1):
  xenomai: Add choice for Cobalt/Mercury core

 package/xenomai/Config.in  | 30 ++++++++++++++++++++++++++++++
 package/xenomai/xenomai.mk |  4 ++++
 2 files changed, 34 insertions(+)

-- 
2.12.1

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Pawel Sikora]

Add an option choice for Cobalt or Mercury core
depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.

With this option enabled and with appropriate patch
applied, default option will be Cobalt core.

With this option disabled, so in case of building
Xenomai userspace with the native Linux Kernel,
Mercury core will be used as default.

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
 package/xenomai/Config.in  | 30 ++++++++++++++++++++++++++++++
 package/xenomai/xenomai.mk |  4 ++++
 2 files changed, 34 insertions(+)

diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
index b548ee810..b8c9430f5 100644
--- a/package/xenomai/Config.in
+++ b/package/xenomai/Config.in
@@ -51,6 +51,36 @@ config BR2_PACKAGE_XENOMAI_VERSION
 	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
 	  Kernel -> Linux Kernel Extensions menu.
 
+choice
+	prompt "Xenomai core"
+	default BR2_PACKAGE_XENOMAI_MERCURY
+	help
+	  Manually select the Xenomai core. Default option depends if
+	  you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
+	  If yes, then default option will be Cobalt.
+	  Otherwise you can use just the Mercury core with the
+	  native Linux kernel.
+
+config BR2_PACKAGE_XENOMAI_MERCURY
+	bool "Mercury"
+	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
+	help
+	  Select Mercury core for the Xenomai userspace.
+	  If you want Cobalt core, you need to enable
+	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
+	  Linux Kernel Extensions menu.
+
+config BR2_PACKAGE_XENOMAI_COBALT
+	bool "Cobalt"
+	depends on BR2_LINUX_KERNEL_EXT_XENOMAI
+	help
+	  Select Cobalt core for the Xenomai userspace.
+	  If you want Mercury core, you need to disable
+	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
+	  Linux Kernel Extensions menu.
+
+endchoice
+
 config BR2_PACKAGE_XENOMAI_TESTSUITE
 	bool "Install testsuite"
 	help
diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index c9e810e05..dbb07eb33 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -23,6 +23,10 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
 
 XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
 
+ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
+XENOMAI_CONF_OPTS += --with-core=mercury
+endif
+
 define XENOMAI_REMOVE_DEVFILES
 	for i in xeno-config xeno-info wrap-link.sh ; do \
 		rm -f $(TARGET_DIR)/usr/bin/$$i ; \
-- 
2.12.1

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas De Schampheleire]

On Apr 7, 2017 12:42 AM, "Pawel Sikora" <sikor6@gmail.com> wrote:

Add an option choice for Cobalt or Mercury core
depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.

With this option enabled and with appropriate patch
applied, default option will be Cobalt core.

With this option disabled, so in case of building
Xenomai userspace with the native Linux Kernel,
Mercury core will be used as default.

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
 package/xenomai/Config.in  | 30 ++++++++++++++++++++++++++++++
 package/xenomai/xenomai.mk |  4 ++++
 2 files changed, 34 insertions(+)

diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
index b548ee810..b8c9430f5 100644
--- a/package/xenomai/Config.in
+++ b/package/xenomai/Config.in
@@ -51,6 +51,36 @@ config BR2_PACKAGE_XENOMAI_VERSION
          BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
          Kernel -> Linux Kernel Extensions menu.

+choice
+       prompt "Xenomai core"
+       default BR2_PACKAGE_XENOMAI_MERCURY
+       help
+         Manually select the Xenomai core. Default option depends if
+         you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
+         If yes, then default option will be Cobalt.
+         Otherwise you can use just the Mercury core with the
+         native Linux kernel.
+
+config BR2_PACKAGE_XENOMAI_MERCURY
+       bool "Mercury"
+       depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
+       help
+         Select Mercury core for the Xenomai userspace.
+         If you want Cobalt core, you need to enable
+         BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
+         Linux Kernel Extensions menu.
+
+config BR2_PACKAGE_XENOMAI_COBALT
+       bool "Cobalt"
+       depends on BR2_LINUX_KERNEL_EXT_XENOMAI
+       help
+         Select Cobalt core for the Xenomai userspace.
+         If you want Mercury core, you need to disable
+         BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
+         Linux Kernel Extensions menu.
+
+endchoice
+
 config BR2_PACKAGE_XENOMAI_TESTSUITE
        bool "Install testsuite"
        help
diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index c9e810e05..dbb07eb33 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -23,6 +23,10 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR)
install-user

 XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/
--disable-doc-install

+ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
+XENOMAI_CONF_OPTS += --with-core=mercury
+endif


Wouldn't it be clear to have an else here that explicitly sets core=cobalt
? Then we don't rely on the default of xenomai.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170407/14699286/attachment.html>

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas Petazzoni]

Hello,

On Fri, 7 Apr 2017 07:58:12 +0200, Thomas De Schampheleire wrote:

> Wouldn't it be clear to have an else here that explicitly sets core=cobalt
> ? Then we don't rely on the default of xenomai.

Could you fix your e-mail client to properly quote the text you are
replying to? Right now, your e-mail looks exactly like the original
mail from Pawel, just with your answer at the bottom. Hard to see what
comes from the original e-mail, what comes from you.

It was the same when you replied to me about the external toolchain
patches.

Thanks!

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

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas Petazzoni]

Hello,

On Fri,  7 Apr 2017 01:41:39 +0200, Pawel Sikora wrote:

> +choice
> +	prompt "Xenomai core"
> +	default BR2_PACKAGE_XENOMAI_MERCURY
> +	help
> +	  Manually select the Xenomai core. Default option depends if
> +	  you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
> +	  If yes, then default option will be Cobalt.
> +	  Otherwise you can use just the Mercury core with the
> +	  native Linux kernel.
> +
> +config BR2_PACKAGE_XENOMAI_MERCURY
> +	bool "Mercury"
> +	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> +	help
> +	  Select Mercury core for the Xenomai userspace.
> +	  If you want Cobalt core, you need to enable
> +	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> +	  Linux Kernel Extensions menu.
> +
> +config BR2_PACKAGE_XENOMAI_COBALT
> +	bool "Cobalt"
> +	depends on BR2_LINUX_KERNEL_EXT_XENOMAI
> +	help
> +	  Select Cobalt core for the Xenomai userspace.
> +	  If you want Mercury core, you need to disable
> +	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> +	  Linux Kernel Extensions menu.

Does it really make sense to have a "choice" when in fact it's
impossible to have both options of the choice visible at the same time?
One option depends on !BR2_LINUX_KERNEL_EXT_XENOMAI and the other
option depends on BR2_LINUX_KERNEL_EXT_XENOMAI.

I'm not sure how to handle this. Do we automatically switch between
Cobalt and Mercury depending on whether the Xenomai kernel extension is
enabled?

Do we use Mercury by default, and offer a sub-option to explicitly
enable Cobalt when the Linux kernel extension is available?

Thanks,

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

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 08-04-17 15:34, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri,  7 Apr 2017 01:41:39 +0200, Pawel Sikora wrote:
> 
>> +choice
>> +	prompt "Xenomai core"
>> +	default BR2_PACKAGE_XENOMAI_MERCURY
>> +	help
>> +	  Manually select the Xenomai core. Default option depends if
>> +	  you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
>> +	  If yes, then default option will be Cobalt.
>> +	  Otherwise you can use just the Mercury core with the
>> +	  native Linux kernel.
>> +
>> +config BR2_PACKAGE_XENOMAI_MERCURY
>> +	bool "Mercury"
>> +	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
>> +	help
>> +	  Select Mercury core for the Xenomai userspace.
>> +	  If you want Cobalt core, you need to enable
>> +	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
>> +	  Linux Kernel Extensions menu.
>> +
>> +config BR2_PACKAGE_XENOMAI_COBALT
>> +	bool "Cobalt"
>> +	depends on BR2_LINUX_KERNEL_EXT_XENOMAI
>> +	help
>> +	  Select Cobalt core for the Xenomai userspace.
>> +	  If you want Mercury core, you need to disable
>> +	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
>> +	  Linux Kernel Extensions menu.
> 
> Does it really make sense to have a "choice" when in fact it's
> impossible to have both options of the choice visible at the same time?
> One option depends on !BR2_LINUX_KERNEL_EXT_XENOMAI and the other
> option depends on BR2_LINUX_KERNEL_EXT_XENOMAI.
> 
> I'm not sure how to handle this. Do we automatically switch between
> Cobalt and Mercury depending on whether the Xenomai kernel extension is
> enabled?
> 
> Do we use Mercury by default, and offer a sub-option to explicitly
> enable Cobalt when the Linux kernel extension is available?

 The mercury option certainly only makes sense when the Xenomai extension in the
kernel is NOT selected, so that can be kept.

 However, the cobalt option still makes sense if the Xenomai extension is not
selected. For starters, it's possible that the kernel is built outside of
Buildroot. But also it's possible that we use a custom kernel that is already
Xenomai-patched, in which case the Xenomai extension is not used.

 So just remove the dependency from cobalt.

 I think indeed it does make sense to use Mercury by default, except when the
Xenomai extension is selected.

 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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 07-04-17 10:27, Thomas Petazzoni wrote:
> Hello,
> 
> On Fri, 7 Apr 2017 07:58:12 +0200, Thomas De Schampheleire wrote:
> 
>> Wouldn't it be clear to have an else here that explicitly sets core=cobalt
>> ? Then we don't rely on the default of xenomai.
> 
> Could you fix your e-mail client to properly quote the text you are
> replying to? Right now, your e-mail looks exactly like the original
> mail from Pawel, just with your answer at the bottom. Hard to see what
> comes from the original e-mail, what comes from you.

 Based on the headers, I'm afraid that any fixing will have to be done by Google...

 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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Pawel Sikora]

Hi,

2017-04-08 16:22 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:

>
>
> On 08-04-17 15:34, Thomas Petazzoni wrote:
> > Hello,
> >
> > On Fri,  7 Apr 2017 01:41:39 +0200, Pawel Sikora wrote:
> >
> >> +choice
> >> +    prompt "Xenomai core"
> >> +    default BR2_PACKAGE_XENOMAI_MERCURY
> >> +    help
> >> +      Manually select the Xenomai core. Default option depends if
> >> +      you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
> >> +      If yes, then default option will be Cobalt.
> >> +      Otherwise you can use just the Mercury core with the
> >> +      native Linux kernel.
> >> +
> >> +config BR2_PACKAGE_XENOMAI_MERCURY
> >> +    bool "Mercury"
> >> +    depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> >> +    help
> >> +      Select Mercury core for the Xenomai userspace.
> >> +      If you want Cobalt core, you need to enable
> >> +      BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> >> +      Linux Kernel Extensions menu.
> >> +
> >> +config BR2_PACKAGE_XENOMAI_COBALT
> >> +    bool "Cobalt"
> >> +    depends on BR2_LINUX_KERNEL_EXT_XENOMAI
> >> +    help
> >> +      Select Cobalt core for the Xenomai userspace.
> >> +      If you want Mercury core, you need to disable
> >> +      BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> >> +      Linux Kernel Extensions menu.
> >
> > Does it really make sense to have a "choice" when in fact it's
> > impossible to have both options of the choice visible at the same time?
> > One option depends on !BR2_LINUX_KERNEL_EXT_XENOMAI and the other
> > option depends on BR2_LINUX_KERNEL_EXT_XENOMAI.
>
>
Taking into considerations Arnout's suggestions that Cobalt indeed does not
need to have dependency from BR2_LINUX_KERNEL_EXT_XENOMAI
you can really choose between Mercury/Cobalt. So now this makes sense ;-)


> > I'm not sure how to handle this. Do we automatically switch between
> > Cobalt and Mercury depending on whether the Xenomai kernel extension is
> > enabled?
> >
> > Do we use Mercury by default, and offer a sub-option to explicitly
> > enable Cobalt when the Linux kernel extension is available?
>
>  The mercury option certainly only makes sense when the Xenomai extension
> in the
> kernel is NOT selected, so that can be kept.
>
>  However, the cobalt option still makes sense if the Xenomai extension is
> not
> selected. For starters, it's possible that the kernel is built outside of
> Buildroot. But also it's possible that we use a custom kernel that is
> already
> Xenomai-patched, in which case the Xenomai extension is not used.
>
>  So just remove the dependency from cobalt.
>
>  I think indeed it does make sense to use Mercury by default, except when
> the
> Xenomai extension is selected.
>
>  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 mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>

Right Arnout, thanks guys for pointing that - I changed it as you proposed.
I added also an explicit choice for cobalt in an else statement as Thomas
De Schampheleire suggested.

Checked in compile time in Configure, based on output from message:
"checking whether we build for Cobalt or Mercury core... cobalt"

Btw. Guys:

What about support for Xenomai 2.6? Should we split Xenomai into two
packages
for both versions? As it needs different patches that are currently for 3.x
version
and now if someone want to build 2.x will need to take these patches
manually.
So doesn't it really mean now, that the option with prompt for Xenomai
version
will work only for Xenomai >3.x?

What do you think?

Regards,
Pawel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170410/5b774cc7/attachment.html>

[Buildroot] [PATCH v2] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Pawel Sikora]

Add an option choice for Cobalt or Mercury core
depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---

Changes v1 -> v2:
 - explicitly setting Cobalt core  (suggested by Thomas de Schampheleire)
 - removing from Cobalt config dependency from Xenomai being set
   in the Linux Kernel Extensions (Thomas P., Arnout V.)

package/xenomai/Config.in  | 36 ++++++++++++++++++++++++++++++++++++
 package/xenomai/xenomai.mk |  6 ++++++
 2 files changed, 42 insertions(+)

diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
index b548ee810..3d6342c8f 100644
--- a/package/xenomai/Config.in
+++ b/package/xenomai/Config.in
@@ -51,6 +51,42 @@ config BR2_PACKAGE_XENOMAI_VERSION
 	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
 	  Kernel -> Linux Kernel Extensions menu.
 
+choice
+	prompt "Xenomai core"
+	default BR2_PACKAGE_XENOMAI_MERCURY
+	help
+	  Manually select the Xenomai core. Depends if
+	  you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
+	  If yes, then default option will be Cobalt.
+	  Otherwise you can choose between Mercury/Cobalt
+	  depending from your needs.
+
+config BR2_PACKAGE_XENOMAI_MERCURY
+	bool "Mercury"
+	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
+	help
+	  Select Mercury core for the Xenomai userspace.
+	  You want to use it if you have the native Linux Kernel.
+
+	  If you want Cobalt core, you need to either enable
+	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
+	  Linux Kernel Extensions menu or you can choose it
+	  anyway if you use external Linux Kernel with applied
+	  I-pipe patch.
+
+config BR2_PACKAGE_XENOMAI_COBALT
+	bool "Cobalt"
+	help
+	  Select Cobalt core for the Xenomai userspace.
+	  You should have the right I-pipe patch for your
+	  Linux Kernel version, you can add it via
+	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH in the Linux Kernel ->
+	  Linux Kernel Extensions menu or from the interactive prompt
+	  at compile time of Xenomai.
+	  You can also compile it without providing this information
+	  if have an external Linux Kernel that is already patched.
+endchoice
+
 config BR2_PACKAGE_XENOMAI_TESTSUITE
 	bool "Install testsuite"
 	help
diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index c9e810e05..73d9617b1 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -23,6 +23,12 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
 
 XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
 
+ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
+XENOMAI_CONF_OPTS += --with-core=mercury
+else
+XENOMAI_CONF_OPTS += --with-core=cobalt
+endif
+
 define XENOMAI_REMOVE_DEVFILES
 	for i in xeno-config xeno-info wrap-link.sh ; do \
 		rm -f $(TARGET_DIR)/usr/bin/$$i ; \
-- 
2.12.1

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 00:51, Pawel Sikora wrote:
> What about support for Xenomai 2.6? Should we split Xenomai into two packages
> for both versions? As it needs different patches that are currently for 3.x version
> and now if someone want to build 2.x will need to take these patches manually.
> So doesn't it really mean now, that the option with prompt for Xenomai version
> will work only for Xenomai >3.x?

 IIRC when Xenomai 3 support was introduced, we decided to simply drop support
for Xenomai 2.6.

 In fact, I would forego the 'custom Xenomai version' support entirely. I don't
see why you would ever want an older version, and if you need a newer version
than the one in Buildroot you can just bump the package. Does anyone see a
reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]

 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] [PATCH v2] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Arnout Vandecappelle]

 Some small improvements to the help text, otherwise looks OK.

On 10-04-17 01:54, Pawel Sikora wrote:
> Add an option choice for Cobalt or Mercury core
> depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
> 
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> ---
> 
> Changes v1 -> v2:
>  - explicitly setting Cobalt core  (suggested by Thomas de Schampheleire)
>  - removing from Cobalt config dependency from Xenomai being set
>    in the Linux Kernel Extensions (Thomas P., Arnout V.)
> 
> package/xenomai/Config.in  | 36 ++++++++++++++++++++++++++++++++++++
>  package/xenomai/xenomai.mk |  6 ++++++
>  2 files changed, 42 insertions(+)
> 
> diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
> index b548ee810..3d6342c8f 100644
> --- a/package/xenomai/Config.in
> +++ b/package/xenomai/Config.in
> @@ -51,6 +51,42 @@ config BR2_PACKAGE_XENOMAI_VERSION
>  	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
>  	  Kernel -> Linux Kernel Extensions menu.
>  
> +choice
> +	prompt "Xenomai core"
> +	default BR2_PACKAGE_XENOMAI_MERCURY
> +	help
> +	  Manually select the Xenomai core. Depends if
> +	  you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
> +	  If yes, then default option will be Cobalt.
> +	  Otherwise you can choose between Mercury/Cobalt
> +	  depending from your needs.

 All this reference to defaults and dependencies isn't very useful. Instead just:

	  Select the Xenomai core: dual kernel (Cobalt) or
	  native Linux kernel (Mercury).

> +
> +config BR2_PACKAGE_XENOMAI_MERCURY
> +	bool "Mercury"
> +	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> +	help
> +	  Select Mercury core for the Xenomai userspace.
> +	  You want to use it if you have the native Linux Kernel.

	  Select Mercury core (single kernel) for the Xenomai
	  userspace. Use this if you use the native Linux kernel
	  without Xenomai extension.

> +
> +	  If you want Cobalt core, you need to either enable
> +	  BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> +	  Linux Kernel Extensions menu or you can choose it
> +	  anyway if you use external Linux Kernel with applied
> +	  I-pipe patch.

 Remove this second paragraph entirely, since it's about the other choice.

> +
> +config BR2_PACKAGE_XENOMAI_COBALT
> +	bool "Cobalt"
> +	help
> +	  Select Cobalt core for the Xenomai userspace.
> +	  You should have the right I-pipe patch for your
> +	  Linux Kernel version, you can add it via
> +	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH in the Linux Kernel ->
> +	  Linux Kernel Extensions menu or from the interactive prompt
> +	  at compile time of Xenomai.
> +	  You can also compile it without providing this information
> +	  if have an external Linux Kernel that is already patched.

	  Select Cobalt core (dual kernel) for the Xenomai
	  userspace. Use this if you use a Xenomai-patched
	  Linux kernel.

	  If you want to use Cobalt core, your kernel must have
	  the Adeos and Xenomai patches applied to it. You can
	  add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
	  in the Linux Kernel Extensions menu.


 Regards,
 Arnout


> +endchoice
> +
>  config BR2_PACKAGE_XENOMAI_TESTSUITE
>  	bool "Install testsuite"
>  	help
> diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> index c9e810e05..73d9617b1 100644
> --- a/package/xenomai/xenomai.mk
> +++ b/package/xenomai/xenomai.mk
> @@ -23,6 +23,12 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
>  
>  XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
>  
> +ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
> +XENOMAI_CONF_OPTS += --with-core=mercury
> +else
> +XENOMAI_CONF_OPTS += --with-core=cobalt
> +endif
> +
>  define XENOMAI_REMOVE_DEVFILES
>  	for i in xeno-config xeno-info wrap-link.sh ; do \
>  		rm -f $(TARGET_DIR)/usr/bin/$$i ; \
> 

-- 
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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas Petazzoni]

Hello,

On Mon, 10 Apr 2017 11:08:21 +0200, Arnout Vandecappelle wrote:

>  In fact, I would forego the 'custom Xenomai version' support entirely. I don't
> see why you would ever want an older version, and if you need a newer version
> than the one in Buildroot you can just bump the package. Does anyone see a
> reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]

I think the main reason is that Xenomai includes kernel patches, but
only for specific kernel versions. So if you're using a specific kernel
version, you might need to use a specific Xenomai version, and not just
"the latest".

Best regards,

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

[Buildroot] [PATCH v3] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Pawel Sikora]

Add an option choice for Cobalt or Mercury core
depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
Changes v2 -> v3:
 - Corrections in help (Arnout V.)

 package/xenomai/Config.in  | 27 +++++++++++++++++++++++++++
 package/xenomai/xenomai.mk |  6 ++++++
 2 files changed, 33 insertions(+)

diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
index b548ee810..324f5025a 100644
--- a/package/xenomai/Config.in
+++ b/package/xenomai/Config.in
@@ -51,6 +51,33 @@ config BR2_PACKAGE_XENOMAI_VERSION
 	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
 	  Kernel -> Linux Kernel Extensions menu.
 
+choice
+	prompt "Xenomai core"
+	default BR2_PACKAGE_XENOMAI_MERCURY
+	help
+	  Select the Xenomai core: dual kernel (Cobalt)
+	  or native Linux Kernel (Mercury).
+
+config BR2_PACKAGE_XENOMAI_MERCURY
+	bool "Mercury"
+	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
+	help
+	  Select Mercury core for the Xenomai userspace.
+	  You want to use it if you have the native Linux Kernel.
+
+config BR2_PACKAGE_XENOMAI_COBALT
+	bool "Cobalt"
+	help
+	  Select Cobalt core (dual kernel) for the Xenomai
+	  userspace. Use this if you use a Xenomai-patched
+	  Linux kernel.
+
+	  If you want to use Cobalt core, your kernel must have
+	  the Adeos and Xenomai patches applied to it. You can
+	  add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
+	  in the Linux Kernel Extensions menu.
+endchoice
+
 config BR2_PACKAGE_XENOMAI_TESTSUITE
 	bool "Install testsuite"
 	help
diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index c9e810e05..73d9617b1 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -23,6 +23,12 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
 
 XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
 
+ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
+XENOMAI_CONF_OPTS += --with-core=mercury
+else
+XENOMAI_CONF_OPTS += --with-core=cobalt
+endif
+
 define XENOMAI_REMOVE_DEVFILES
 	for i in xeno-config xeno-info wrap-link.sh ; do \
 		rm -f $(TARGET_DIR)/usr/bin/$$i ; \
-- 
2.12.1

[Buildroot] [PATCH v2] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Pawel Sikora]

Hi

2017-04-10 13:11 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:

>  Some small improvements to the help text, otherwise looks OK.
>
> On 10-04-17 01:54, Pawel Sikora wrote:
> > Add an option choice for Cobalt or Mercury core
> > depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
> >
> > Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> > ---
> >
> > Changes v1 -> v2:
> >  - explicitly setting Cobalt core  (suggested by Thomas de Schampheleire)
> >  - removing from Cobalt config dependency from Xenomai being set
> >    in the Linux Kernel Extensions (Thomas P., Arnout V.)
> >
> > package/xenomai/Config.in  | 36 ++++++++++++++++++++++++++++++++++++
> >  package/xenomai/xenomai.mk |  6 ++++++
> >  2 files changed, 42 insertions(+)
> >
> > diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
> > index b548ee810..3d6342c8f 100644
> > --- a/package/xenomai/Config.in
> > +++ b/package/xenomai/Config.in
> > @@ -51,6 +51,42 @@ config BR2_PACKAGE_XENOMAI_VERSION
> >         BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
> >         Kernel -> Linux Kernel Extensions menu.
> >
> > +choice
> > +     prompt "Xenomai core"
> > +     default BR2_PACKAGE_XENOMAI_MERCURY
> > +     help
> > +       Manually select the Xenomai core. Depends if
> > +       you selected BR2_LINUX_KERNEL_EXT_XENOMAI.
> > +       If yes, then default option will be Cobalt.
> > +       Otherwise you can choose between Mercury/Cobalt
> > +       depending from your needs.
>
>  All this reference to defaults and dependencies isn't very useful.
> Instead just:
>
>           Select the Xenomai core: dual kernel (Cobalt) or
>           native Linux kernel (Mercury).
>
> > +
> > +config BR2_PACKAGE_XENOMAI_MERCURY
> > +     bool "Mercury"
> > +     depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> > +     help
> > +       Select Mercury core for the Xenomai userspace.
> > +       You want to use it if you have the native Linux Kernel.
>
>           Select Mercury core (single kernel) for the Xenomai
>           userspace. Use this if you use the native Linux kernel
>           without Xenomai extension.
>
> > +
> > +       If you want Cobalt core, you need to either enable
> > +       BR2_LINUX_KERNEL_EXT_XENOMAI in the Linux Kernel ->
> > +       Linux Kernel Extensions menu or you can choose it
> > +       anyway if you use external Linux Kernel with applied
> > +       I-pipe patch.
>
>  Remove this second paragraph entirely, since it's about the other choice.
>
> > +
> > +config BR2_PACKAGE_XENOMAI_COBALT
> > +     bool "Cobalt"
> > +     help
> > +       Select Cobalt core for the Xenomai userspace.
> > +       You should have the right I-pipe patch for your
> > +       Linux Kernel version, you can add it via
> > +       BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH in the Linux Kernel ->
> > +       Linux Kernel Extensions menu or from the interactive prompt
> > +       at compile time of Xenomai.
> > +       You can also compile it without providing this information
> > +       if have an external Linux Kernel that is already patched.
>
>           Select Cobalt core (dual kernel) for the Xenomai
>           userspace. Use this if you use a Xenomai-patched
>           Linux kernel.
>
>           If you want to use Cobalt core, your kernel must have
>           the Adeos and Xenomai patches applied to it. You can
>           add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
>           in the Linux Kernel Extensions menu.
>
>
>  Regards,
>  Arnout
>
>
> > +endchoice
> > +
> >  config BR2_PACKAGE_XENOMAI_TESTSUITE
> >       bool "Install testsuite"
> >       help
> > diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> > index c9e810e05..73d9617b1 100644
> > --- a/package/xenomai/xenomai.mk
> > +++ b/package/xenomai/xenomai.mk
> > @@ -23,6 +23,12 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR)
> install-user
> >
> >  XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/
> --disable-doc-install
> >
> > +ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
> > +XENOMAI_CONF_OPTS += --with-core=mercury
> > +else
> > +XENOMAI_CONF_OPTS += --with-core=cobalt
> > +endif
> > +
> >  define XENOMAI_REMOVE_DEVFILES
> >       for i in xeno-config xeno-info wrap-link.sh ; do \
> >               rm -f $(TARGET_DIR)/usr/bin/$$i ; \
> >
>
> --
> 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
>

Corrections in patch v3, Thanks Arnout!

Regards,
Pawel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170410/a6072b1a/attachment.html>

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 13:51, Thomas Petazzoni wrote:
> Hello,
> 
> On Mon, 10 Apr 2017 11:08:21 +0200, Arnout Vandecappelle wrote:
> 
>>  In fact, I would forego the 'custom Xenomai version' support entirely. I don't
>> see why you would ever want an older version, and if you need a newer version
>> than the one in Buildroot you can just bump the package. Does anyone see a
>> reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]
> 
> I think the main reason is that Xenomai includes kernel patches, but
> only for specific kernel versions. So if you're using a specific kernel
> version, you might need to use a specific Xenomai version, and not just
> "the latest".

 As far as I remember, older versions weren't removed that often, though they
did sometimes get updated to a later release of that branch. But I think in
these cases you just want to point to a specific version of the ipipe patch, and
don't want to use an older and potentially buggy xenomai version.

 While checking this, by the way, I discovered that the --default option to
prepare-kernel.sh no longer works (i.e., it no longer autodiscovers the patch to
apply). So linux-ext-xenomai.mk should be updated to disallow an empty ipipe
patch. Pawel, could you look into this? It should either autodiscover the patch
to apply similar to how rtai does it, or it should just $(error) in case
XENOMAI_ADEOS_PATCH is empty, similar to the handling of LINUX_KCONFIG_FILE (but
remember to check BR_BUILDING in that case...). I think autodiscovering is a bit
fragile, though.

 Regards,
 Arnout

> 
> Best regards,
> 
> Thomas
> 

-- 
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] [PATCH v3] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 14:32, Pawel Sikora wrote:
> Add an option choice for Cobalt or Mercury core
> depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
> 
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>

Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>

 As noticed, this will collide with the SMP patch.

 Pawel, if you would resend a v4 where both patches are kept together in a patch
series, make sure that you copy my Reviewed-by tag (put it below your
Signed-off-by).

 Regards,
 Arnout

> ---
> Changes v2 -> v3:
>  - Corrections in help (Arnout V.)
> 
>  package/xenomai/Config.in  | 27 +++++++++++++++++++++++++++
>  package/xenomai/xenomai.mk |  6 ++++++
>  2 files changed, 33 insertions(+)
> 
> diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
> index b548ee810..324f5025a 100644
> --- a/package/xenomai/Config.in
> +++ b/package/xenomai/Config.in
> @@ -51,6 +51,33 @@ config BR2_PACKAGE_XENOMAI_VERSION
>  	  BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
>  	  Kernel -> Linux Kernel Extensions menu.
>  
> +choice
> +	prompt "Xenomai core"
> +	default BR2_PACKAGE_XENOMAI_MERCURY
> +	help
> +	  Select the Xenomai core: dual kernel (Cobalt)
> +	  or native Linux Kernel (Mercury).
> +
> +config BR2_PACKAGE_XENOMAI_MERCURY
> +	bool "Mercury"
> +	depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> +	help
> +	  Select Mercury core for the Xenomai userspace.
> +	  You want to use it if you have the native Linux Kernel.
> +
> +config BR2_PACKAGE_XENOMAI_COBALT
> +	bool "Cobalt"
> +	help
> +	  Select Cobalt core (dual kernel) for the Xenomai
> +	  userspace. Use this if you use a Xenomai-patched
> +	  Linux kernel.
> +
> +	  If you want to use Cobalt core, your kernel must have
> +	  the Adeos and Xenomai patches applied to it. You can
> +	  add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
> +	  in the Linux Kernel Extensions menu.
> +endchoice
> +
>  config BR2_PACKAGE_XENOMAI_TESTSUITE
>  	bool "Install testsuite"
>  	help
> diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> index c9e810e05..73d9617b1 100644
> --- a/package/xenomai/xenomai.mk
> +++ b/package/xenomai/xenomai.mk
> @@ -23,6 +23,12 @@ XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
>  
>  XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
>  
> +ifeq ($(BR2_PACKAGE_XENOMAI_MERCURY),y)
> +XENOMAI_CONF_OPTS += --with-core=mercury
> +else
> +XENOMAI_CONF_OPTS += --with-core=cobalt
> +endif
> +
>  define XENOMAI_REMOVE_DEVFILES
>  	for i in xeno-config xeno-info wrap-link.sh ; do \
>  		rm -f $(TARGET_DIR)/usr/bin/$$i ; \
> 

-- 
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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas De Schampheleire]

On Mon, Apr 10, 2017 at 11:08 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 10-04-17 00:51, Pawel Sikora wrote:
>> What about support for Xenomai 2.6? Should we split Xenomai into two packages
>> for both versions? As it needs different patches that are currently for 3.x version
>> and now if someone want to build 2.x will need to take these patches manually.
>> So doesn't it really mean now, that the option with prompt for Xenomai version
>> will work only for Xenomai >3.x?
>
>  IIRC when Xenomai 3 support was introduced, we decided to simply drop support
> for Xenomai 2.6.
>
>  In fact, I would forego the 'custom Xenomai version' support entirely. I don't
> see why you would ever want an older version, and if you need a newer version
> than the one in Buildroot you can just bump the package. Does anyone see a
> reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]
>

[sorry for the earlier mail problems, seems the Gmail Android app has
been 'improved' to mess up inline replies...]

In the past, there have been several cases where updates were made to
the Mercury core of Xenomai that required changes in existing
applications. Possibly this depended on how exactly you link to it and
which startup options you give, but anyway this is a situation where
being able to select a non-latest xenomai version can be useful, at
least in a transition phase.

Best regards,
Thomas

[Buildroot] [PATCH v3] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Thomas De Schampheleire]

On Mon, Apr 10, 2017 at 2:32 PM, Pawel Sikora <sikor6@gmail.com> wrote:
> Add an option choice for Cobalt or Mercury core
> depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
>
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> ---
> Changes v2 -> v3:
>  - Corrections in help (Arnout V.)
>
>  package/xenomai/Config.in  | 27 +++++++++++++++++++++++++++
>  package/xenomai/xenomai.mk |  6 ++++++
>  2 files changed, 33 insertions(+)
>
> diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
> index b548ee810..324f5025a 100644
> --- a/package/xenomai/Config.in
> +++ b/package/xenomai/Config.in
> @@ -51,6 +51,33 @@ config BR2_PACKAGE_XENOMAI_VERSION
>           BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
>           Kernel -> Linux Kernel Extensions menu.
>
> +choice
> +       prompt "Xenomai core"
> +       default BR2_PACKAGE_XENOMAI_MERCURY
> +       help
> +         Select the Xenomai core: dual kernel (Cobalt)
> +         or native Linux Kernel (Mercury).
> +
> +config BR2_PACKAGE_XENOMAI_MERCURY
> +       bool "Mercury"
> +       depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> +       help
> +         Select Mercury core for the Xenomai userspace.
> +         You want to use it if you have the native Linux Kernel.
> +
> +config BR2_PACKAGE_XENOMAI_COBALT
> +       bool "Cobalt"
> +       help
> +         Select Cobalt core (dual kernel) for the Xenomai
> +         userspace. Use this if you use a Xenomai-patched
> +         Linux kernel.
> +
> +         If you want to use Cobalt core, your kernel must have

the Cobalt core

> +         the Adeos and Xenomai patches applied to it. You can
> +         add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
> +         in the Linux Kernel Extensions menu.

With the latest updates, the term 'I-pipe' has disappeared here, I
think it is a relevant term that helps clarifying 'Adeos', no?

More in general: I wonder which level of help we need to provide here.
I expect that people's choice of either Cobalt or Mercury cannot be
driven by the current help above. The choice has severe impact on your
application and system. We could try to extend the help, e.g.
clarifying that only the cobalt core can provide real real-time
guarantees, and that the mercury core's real-time strictness fully
depends on the linux kernel. But perhaps it may be better to
explicitly refer to the Xenomai documentation to make a proper
decision.

Best regards,
Thomas

[Buildroot] [PATCH v3] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Pawel Sikora]

Hi,

2017-04-10 21:31 GMT+02:00 Thomas De Schampheleire <
patrickdepinguin@gmail.com>:

> On Mon, Apr 10, 2017 at 2:32 PM, Pawel Sikora <sikor6@gmail.com> wrote:
> > Add an option choice for Cobalt or Mercury core
> > depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
> >
> > Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> > ---
> > Changes v2 -> v3:
> >  - Corrections in help (Arnout V.)
> >
> >  package/xenomai/Config.in  | 27 +++++++++++++++++++++++++++
> >  package/xenomai/xenomai.mk |  6 ++++++
> >  2 files changed, 33 insertions(+)
> >
> > diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
> > index b548ee810..324f5025a 100644
> > --- a/package/xenomai/Config.in
> > +++ b/package/xenomai/Config.in
> > @@ -51,6 +51,33 @@ config BR2_PACKAGE_XENOMAI_VERSION
> >           BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
> >           Kernel -> Linux Kernel Extensions menu.
> >
> > +choice
> > +       prompt "Xenomai core"
> > +       default BR2_PACKAGE_XENOMAI_MERCURY
> > +       help
> > +         Select the Xenomai core: dual kernel (Cobalt)
> > +         or native Linux Kernel (Mercury).
> > +
> > +config BR2_PACKAGE_XENOMAI_MERCURY
> > +       bool "Mercury"
> > +       depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
> > +       help
> > +         Select Mercury core for the Xenomai userspace.
> > +         You want to use it if you have the native Linux Kernel.
> > +
> > +config BR2_PACKAGE_XENOMAI_COBALT
> > +       bool "Cobalt"
> > +       help
> > +         Select Cobalt core (dual kernel) for the Xenomai
> > +         userspace. Use this if you use a Xenomai-patched
> > +         Linux kernel.
> > +
> > +         If you want to use Cobalt core, your kernel must have
>
> the Cobalt core
>
> > +         the Adeos and Xenomai patches applied to it. You can
> > +         add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
> > +         in the Linux Kernel Extensions menu.
>
> With the latest updates, the term 'I-pipe' has disappeared here, I
> think it is a relevant term that helps clarifying 'Adeos', no?
>

I think I don't get it, could you explain this in detail? Is it that name
of the prompt for patch in Linux Kernel Extensions have just 'Adeos'
in name and should have I-pipe or something else?


>
> More in general: I wonder which level of help we need to provide here.
> I expect that people's choice of either Cobalt or Mercury cannot be
> driven by the current help above. The choice has severe impact on your
> application and system. We could try to extend the help, e.g.
> clarifying that only the cobalt core can provide real real-time
> guarantees, and that the mercury core's real-time strictness fully
> depends on the linux kernel. But perhaps it may be better to
> explicitly refer to the Xenomai documentation to make a proper
> decision.
>

Hmm... You're right. But I think that choice of Xenomai Core should be
driven by knowledge from the documentation - Xenomai documentation.

What about adding just information with clarification about what one can
expect from Mercury/Cobalt as you described above and pointing to
Xenomai documentation for further details?

Regards,
Pawel


>
> Best regards,
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170410/a12cebd8/attachment.html>

[Buildroot] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Pawel Sikora]

Hi,

2017-04-10 15:33 GMT+02:00 Arnout Vandecappelle <arnout@mind.be>:

>
>
> On 10-04-17 13:51, Thomas Petazzoni wrote:
> > Hello,
> >
> > On Mon, 10 Apr 2017 11:08:21 +0200, Arnout Vandecappelle wrote:
> >
> >>  In fact, I would forego the 'custom Xenomai version' support entirely.
> I don't
> >> see why you would ever want an older version, and if you need a newer
> version
> >> than the one in Buildroot you can just bump the package. Does anyone
> see a
> >> reason to support multiple versions? [Adding ThomasDS in Cc to answer
> that.]
> >
> > I think the main reason is that Xenomai includes kernel patches, but
> > only for specific kernel versions. So if you're using a specific kernel
> > version, you might need to use a specific Xenomai version, and not just
> > "the latest".
>
>  As far as I remember, older versions weren't removed that often, though
> they
> did sometimes get updated to a later release of that branch. But I think in
> these cases you just want to point to a specific version of the ipipe
> patch, and
> don't want to use an older and potentially buggy xenomai version.
>
>  While checking this, by the way, I discovered that the --default option to
> prepare-kernel.sh no longer works (i.e., it no longer autodiscovers the
> patch to
> apply). So linux-ext-xenomai.mk should be updated to disallow an empty
> ipipe
> patch. Pawel, could you look into this? It should either autodiscover the
> patch
> to apply similar to how rtai does it, or it should just $(error) in case
> XENOMAI_ADEOS_PATCH is empty, similar to the handling of
> LINUX_KCONFIG_FILE (but
> remember to check BR_BUILDING in that case...). I think autodiscovering is
> a bit
> fragile, though.
>

Hmm ok, I will look at this, but most probably not until wednesday (quite a
lot to do on university now)

But... when there is no patch provided, you are prompted for it at a stage
of kernel patching, isn't this better than error?
Of course, it would be good to have a working autodiscovery (but not so
urgent, right?)

Regards,
Pawel



>
>  Regards,
>  Arnout
>
> >
> > Best regards,
> >
> > Thomas
> >
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170410/0b4fe759/attachment.html>

[Buildroot] [PATCH v3] xenomai: Add choice for enabling/disabling Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 22:01, Pawel Sikora wrote:
> Hi,
> 
> 2017-04-10 21:31 GMT+02:00 Thomas De Schampheleire <patrickdepinguin@gmail.com
> <mailto:patrickdepinguin@gmail.com>>:
> 
>     On Mon, Apr 10, 2017 at 2:32 PM, Pawel Sikora <sikor6@gmail.com
>     <mailto:sikor6@gmail.com>> wrote:
>     > Add an option choice for Cobalt or Mercury core
>     > depending on option BR2_LINUX_KERNEL_EXT_XENOMAI.
>     >
>     > Signed-off-by: Pawel Sikora <sikor6 at gmail.com <mailto:sikor6@gmail.com>>
>     > ---
>     > Changes v2 -> v3:
>     >  - Corrections in help (Arnout V.)
>     >
>     >  package/xenomai/Config.in  | 27 +++++++++++++++++++++++++++
>     >  package/xenomai/xenomai.mk <http://xenomai.mk> |  6 ++++++
>     >  2 files changed, 33 insertions(+)
>     >
>     > diff --git a/package/xenomai/Config.in b/package/xenomai/Config.in
>     > index b548ee810..324f5025a 100644
>     > --- a/package/xenomai/Config.in
>     > +++ b/package/xenomai/Config.in
>     > @@ -51,6 +51,33 @@ config BR2_PACKAGE_XENOMAI_VERSION
>     >           BR2_LINUX_KERNEL_EXT_XENOMAI_ADEOS_PATCH, in the Linux
>     >           Kernel -> Linux Kernel Extensions menu.
>     >
>     > +choice
>     > +       prompt "Xenomai core"
>     > +       default BR2_PACKAGE_XENOMAI_MERCURY
>     > +       help
>     > +         Select the Xenomai core: dual kernel (Cobalt)
>     > +         or native Linux Kernel (Mercury).
>     > +
>     > +config BR2_PACKAGE_XENOMAI_MERCURY
>     > +       bool "Mercury"
>     > +       depends on !BR2_LINUX_KERNEL_EXT_XENOMAI
>     > +       help
>     > +         Select Mercury core for the Xenomai userspace.
>     > +         You want to use it if you have the native Linux Kernel.
>     > +
>     > +config BR2_PACKAGE_XENOMAI_COBALT
>     > +       bool "Cobalt"
>     > +       help
>     > +         Select Cobalt core (dual kernel) for the Xenomai
>     > +         userspace. Use this if you use a Xenomai-patched
>     > +         Linux kernel.
>     > +
>     > +         If you want to use Cobalt core, your kernel must have
> 
>     the Cobalt core
> 
>     > +         the Adeos and Xenomai patches applied to it. You can
>     > +         add these through the BR2_LINUX_KERNEL_EXT_XENOMAI option
>     > +         in the Linux Kernel Extensions menu.
> 
>     With the latest updates, the term 'I-pipe' has disappeared here, I
>     think it is a relevant term that helps clarifying 'Adeos', no?
> 
> 
> I think I don't get it, could you explain this in detail? Is it that name
> of the prompt for patch in Linux Kernel Extensions have just 'Adeos'
> in name and should have I-pipe or something else?

 I think he just means to replace Adeos with Adeos I-Pipe.

>  
> 
> 
>     More in general: I wonder which level of help we need to provide here.
>     I expect that people's choice of either Cobalt or Mercury cannot be
>     driven by the current help above. The choice has severe impact on your
>     application and system. We could try to extend the help, e.g.
>     clarifying that only the cobalt core can provide real real-time
>     guarantees, and that the mercury core's real-time strictness fully
>     depends on the linux kernel. But perhaps it may be better to
>     explicitly refer to the Xenomai documentation to make a proper
>     decision.
> 
> 
> Hmm... You're right. But I think that choice of Xenomai Core should be
> driven by knowledge from the documentation - Xenomai documentation.
> 
> What about adding just information with clarification about what one can
> expect from Mercury/Cobalt as you described above and pointing to
> Xenomai documentation for further details?

 In my view, we indeed can't provide enough documentation in the help text to
help the user make the choice between Cobalt and Mercury. So it doesn't make
sense adding a very long text here. But the Xenomai documentation about this is
quite clear and extensive, and I think we can assume that the user has read some
of that before enabling Xenomai.

 What we do need in the help text is:

- remind the user that Cobalt is the dual kernel and Mercury is the unikernel;

- remind the user that for Cobalt, he has to make sure that the kernel is
properly patched.


 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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 21:20, Thomas De Schampheleire wrote:
> On Mon, Apr 10, 2017 at 11:08 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>
>>
>> On 10-04-17 00:51, Pawel Sikora wrote:
>>> What about support for Xenomai 2.6? Should we split Xenomai into two packages
>>> for both versions? As it needs different patches that are currently for 3.x version
>>> and now if someone want to build 2.x will need to take these patches manually.
>>> So doesn't it really mean now, that the option with prompt for Xenomai version
>>> will work only for Xenomai >3.x?
>>
>>  IIRC when Xenomai 3 support was introduced, we decided to simply drop support
>> for Xenomai 2.6.
>>
>>  In fact, I would forego the 'custom Xenomai version' support entirely. I don't
>> see why you would ever want an older version, and if you need a newer version
>> than the one in Buildroot you can just bump the package. Does anyone see a
>> reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]
>>
> 
> [sorry for the earlier mail problems, seems the Gmail Android app has
> been 'improved' to mess up inline replies...]

 So, what did you do to fix it? Maybe something needs to be added to the manual? :-)


> In the past, there have been several cases where updates were made to
> the Mercury core of Xenomai that required changes in existing
> applications. Possibly this depended on how exactly you link to it and
> which startup options you give, but anyway this is a situation where
> being able to select a non-latest xenomai version can be useful, at
> least in a transition phase.

 OK, makes sense. It's a bit risky with our patches, but I guess there's no
other option.

 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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Arnout Vandecappelle]

On 10-04-17 22:21, Pawel Sikora wrote:
> Hi,
> 
> 2017-04-10 15:33 GMT+02:00 Arnout Vandecappelle <arnout@mind.be
> <mailto:arnout@mind.be>>:
[snip]
>      While checking this, by the way, I discovered that the --default option to
>     prepare-kernel.sh no longer works (i.e., it no longer autodiscovers the patch to
>     apply). So linux-ext-xenomai.mk <http://linux-ext-xenomai.mk> should be
>     updated to disallow an empty ipipe
>     patch. Pawel, could you look into this? It should either autodiscover the patch
>     to apply similar to how rtai does it, or it should just $(error) in case
>     XENOMAI_ADEOS_PATCH is empty, similar to the handling of LINUX_KCONFIG_FILE (but
>     remember to check BR_BUILDING in that case...). I think autodiscovering is a bit
>     fragile, though.
> 
> 
> Hmm ok, I will look at this, but most probably not until wednesday (quite a lot
> to do on university now)
> 
> But... when there is no patch provided, you are prompted for it at a stage of
> kernel patching, isn't this better than error?

 No. Once you type 'make', the build should proceed non-interactively. The build
can take a very long time, so people will start it and then go away to do
something else. You don't want to return and see that it has stopped after five
minutes with some stupid prompt. And anyway, at that point you probably can't
make sense of this prompt.

 That's also the reason why we have an explicit error for e.g. a non-existing
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE.


> Of course, it would be good to have a working autodiscovery (but not so urgent,
> right?)

 Obviously not so urgent. Would be nice to have it fixed before the 2017.05 release.

 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] [PATCH 1/1] xenomai: Add choice for Cobalt/Mercury core

[Thomas De Schampheleire]

On Mon, Apr 10, 2017 at 11:14 PM, Arnout Vandecappelle <arnout@mind.be> wrote:
>
>
> On 10-04-17 21:20, Thomas De Schampheleire wrote:
>> On Mon, Apr 10, 2017 at 11:08 AM, Arnout Vandecappelle <arnout@mind.be> wrote:
>>>
>>>
>>> On 10-04-17 00:51, Pawel Sikora wrote:
>>>> What about support for Xenomai 2.6? Should we split Xenomai into two packages
>>>> for both versions? As it needs different patches that are currently for 3.x version
>>>> and now if someone want to build 2.x will need to take these patches manually.
>>>> So doesn't it really mean now, that the option with prompt for Xenomai version
>>>> will work only for Xenomai >3.x?
>>>
>>>  IIRC when Xenomai 3 support was introduced, we decided to simply drop support
>>> for Xenomai 2.6.
>>>
>>>  In fact, I would forego the 'custom Xenomai version' support entirely. I don't
>>> see why you would ever want an older version, and if you need a newer version
>>> than the one in Buildroot you can just bump the package. Does anyone see a
>>> reason to support multiple versions? [Adding ThomasDS in Cc to answer that.]
>>>
>>
>> [sorry for the earlier mail problems, seems the Gmail Android app has
>> been 'improved' to mess up inline replies...]
>
>  So, what did you do to fix it? Maybe something needs to be added to the manual? :-)
>

I just stopped sending mail via the app :-)
I should revisit this at some point, I'm counting on other people
reporting the problem and then Gmail to fix it... :-o