[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[Thomas Petazzoni]

Hello,

On Tue, 21 Mar 2017 00:33:47 +0100, sikor6 at gmail.com wrote:
> From: Pawel Sikora <sikor6@gmail.com>
> 
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>

Thanks a lot for looking at the Xenomai package. It hasn't been updated
in a while.

> ---
>  package/xenomai/xenomai.hash | 2 +-
>  package/xenomai/xenomai.mk   | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/package/xenomai/xenomai.hash b/package/xenomai/xenomai.hash
> index 4d74472ee..e41859343 100644
> --- a/package/xenomai/xenomai.hash
> +++ b/package/xenomai/xenomai.hash
> @@ -1,2 +1,2 @@
>  # Locally computed;
> -sha256  b6ff723cb0f3b1c2c4e15bccfd114b248dea1b4164a0ac0e612815379ce7caf8  xenomai-2.6.4.tar.bz2
> +sha256  4c396b4d447efd414c4d7c0894f97ef52b4ec45c87f512c14adee981a45f0e3b  xenomai-3.0.3.tar.bz2
> diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> index 6e0e44163..28875b944 100644
> --- a/package/xenomai/xenomai.mk
> +++ b/package/xenomai/xenomai.mk
> @@ -6,7 +6,7 @@
>  
>  XENOMAI_VERSION = $(call qstrip,$(BR2_PACKAGE_XENOMAI_VERSION))
>  ifeq ($(XENOMAI_VERSION),)
> -XENOMAI_VERSION = 2.6.4
> +XENOMAI_VERSION = 3.0.3

My understanding was that Xenomai 3.x was significantly different from
Xenomai 2.x. Should we support both versions? Is Xenomai 3.x now old
enough that Xenomai 2.x is considered legacy? What problems will people
currently using Xenomai 2.x face if we ask them to move to Xenomai 3.x?

Thanks!

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

[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[Paweł Sikora]

Hi Thomas!

Thanks for prompt response ;-)

I was testing building Xenomai against kernel 4.4.43 (for latest I-Pipe
patch) for Armv7

Btw. Regarding your concerns I think it would be ok to support both
versions, as
version 2.6.x supports only kernels 2.4, 2.6.x and 3.x as it can be found
in script for
preparing the kernel in Xenomai (2.6.4) package:

*~/P/s/z/g/buildroot ??? cat
output/build/xenomai-2.6.4/scripts/prepare-kernel.sh | grep -A 8 "Linux
v2.6"*
    #  Linux v2.6 and 3.x section
    #
    2.6|3.*)
    config_file=Kconfig
    patch_architecture_specific="y"

(Please correct me if I am wrong or if I missed something)

So when building a Xenomai 2.6.4 and preparing Linux for 4.4.43 I've got an
error
saying that it's unsupported kernel. That's why I decided to bump version
package
for me, and I thought that it is a good idea for all either. But know I
think it would
be good to support both versions to not leave users with 2.6 and 3.x...

Btw. JFYI I tested it in runtime on Zybo Zynq-7000. Logs:

# uname -a
Linux buildroot 4.4.43-ipipe #1 SMP Sun Mar 19 12:47:52 CET 2017 armv7l
GNU/Linux
# xeno-test
Started child 96: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ testdir=/usr/bin
+ /usr/bin/smokey --run
arith OK
bufp skipped (no kernel support)
cpu_affinity skipped (no kernel support)
iddp skipped (no kernel support)
leaks OK
net_packet_dgram skipped (no kernel support)
net_packet_raw skipped (no kernel support)
net_udp skipped (no kernel support)
...
# dmesg | grep Xenomai
[    0.226384] [Xenomai] scheduling class idle registered.
[    0.226415] [Xenomai] scheduling class rt registered.
[    0.226542] I-pipe: head domain Xenomai registered.
[    0.228182] [Xenomai] Cobalt v3.0.3 (Groovy Cosmic Halo)


Toolchain used in Buildroot configurations:
glibc 2.24
gcc 5.x

I-Pipe patch:
ipipe-core-4.4.43-arm-7.patch

Linux:
4.4.43

Tested in runtime on HW Platform:
Xilinx Zybo Zynq-7000

I thought it would be nice to add it.

So... what do you propose now? I am quiet new in case of introducing
my changes to buildroot code and I think I would need a little of guidance
here
if we want to do a support for both versions.

Kind Regards,
Pawel

---


*Pozdrawiam,*
*Pawe? Sikora*



*Pozdrawiam,*
*Pawe? Sikora*

2017-03-20 23:40 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Hello,
>
> On Tue, 21 Mar 2017 00:33:47 +0100, sikor6 at gmail.com wrote:
> > From: Pawel Sikora <sikor6@gmail.com>
> >
> > Signed-off-by: Pawel Sikora <sikor6@gmail.com>
>
> Thanks a lot for looking at the Xenomai package. It hasn't been updated
> in a while.
>
> > ---
> >  package/xenomai/xenomai.hash | 2 +-
> >  package/xenomai/xenomai.mk   | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/package/xenomai/xenomai.hash b/package/xenomai/xenomai.hash
> > index 4d74472ee..e41859343 100644
> > --- a/package/xenomai/xenomai.hash
> > +++ b/package/xenomai/xenomai.hash
> > @@ -1,2 +1,2 @@
> >  # Locally computed;
> > -sha256  b6ff723cb0f3b1c2c4e15bccfd114b248dea1b4164a0ac0e612815379ce7caf8
> xenomai-2.6.4.tar.bz2
> > +sha256  4c396b4d447efd414c4d7c0894f97ef52b4ec45c87f512c14adee981a45f0e3b
> xenomai-3.0.3.tar.bz2
> > diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> > index 6e0e44163..28875b944 100644
> > --- a/package/xenomai/xenomai.mk
> > +++ b/package/xenomai/xenomai.mk
> > @@ -6,7 +6,7 @@
> >
> >  XENOMAI_VERSION = $(call qstrip,$(BR2_PACKAGE_XENOMAI_VERSION))
> >  ifeq ($(XENOMAI_VERSION),)
> > -XENOMAI_VERSION = 2.6.4
> > +XENOMAI_VERSION = 3.0.3
>
> My understanding was that Xenomai 3.x was significantly different from
> Xenomai 2.x. Should we support both versions? Is Xenomai 3.x now old
> enough that Xenomai 2.x is considered legacy? What problems will people
> currently using Xenomai 2.x face if we ask them to move to Xenomai 3.x?
>
> Thanks!
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170321/33b205ba/attachment.html>

[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[sikor6 at gmail.com]

From: Pawel Sikora <sikor6@gmail.com>

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
 package/xenomai/xenomai.hash | 2 +-
 package/xenomai/xenomai.mk   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/xenomai/xenomai.hash b/package/xenomai/xenomai.hash
index 4d74472ee..e41859343 100644
--- a/package/xenomai/xenomai.hash
+++ b/package/xenomai/xenomai.hash
@@ -1,2 +1,2 @@
 # Locally computed;
-sha256  b6ff723cb0f3b1c2c4e15bccfd114b248dea1b4164a0ac0e612815379ce7caf8  xenomai-2.6.4.tar.bz2
+sha256  4c396b4d447efd414c4d7c0894f97ef52b4ec45c87f512c14adee981a45f0e3b  xenomai-3.0.3.tar.bz2
diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index 6e0e44163..28875b944 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -6,7 +6,7 @@
 
 XENOMAI_VERSION = $(call qstrip,$(BR2_PACKAGE_XENOMAI_VERSION))
 ifeq ($(XENOMAI_VERSION),)
-XENOMAI_VERSION = 2.6.4
+XENOMAI_VERSION = 3.0.3
 else
 BR_NO_CHECK_HASH_FOR += $(XENOMAI_SOURCE)
 endif
-- 
2.12.0

[Buildroot] [PATCH 2/3] remove: 0001-bfin-remove-inline-keyword.patch

[sikor6 at gmail.com]

From: Pawel Sikora <sikor6@gmail.com>

Remove 0001-bfin-remove-inline-keyword.patch due to bumping
Xenomai to version 3.0.3

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
 .../xenomai/0001-bfin-remove-inline-keyword.patch  | 62 ----------------------
 1 file changed, 62 deletions(-)
 delete mode 100644 package/xenomai/0001-bfin-remove-inline-keyword.patch

diff --git a/package/xenomai/0001-bfin-remove-inline-keyword.patch b/package/xenomai/0001-bfin-remove-inline-keyword.patch
deleted file mode 100644
index 376bd21c3..000000000
--- a/package/xenomai/0001-bfin-remove-inline-keyword.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From 2a96c8bbe19a193d9ae6d0780fc274abc4df03e3 Mon Sep 17 00:00:00 2001
-From: Romain Naour <romain.naour@gmail.com>
-Date: Sat, 5 Nov 2016 19:09:00 +0100
-Subject: [PATCH] bfin: remove inline keyword
-
-Xenomai user space tools fail to build for bfin target since it's
-provide it's own pthread_atfork(), shm_open() and shm_unlink()
-definition using the inline keyword and weak attribute.
-
-With gcc 5+ the weak attribute is discarded by the inline keyword,
-so each symbol are global and are redefined several time while
-linking.
-
-Fixes:
-http://autobuild.buildroot.net/results/0c2/0c2e5eb4edd4f9427f61d3c9b67a12a7a0e24140
-
-Patch status: upstream,
-https://git.xenomai.org/xenomai-2.6.git/commit/?id=917dcebb26ec492f276cdc3b55867aa90e01fa12
-
-Signed-off-by: Romain Naour <romain.naour@gmail.com>
----
- include/asm-blackfin/syscall.h | 10 +++++-----
- 1 file changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/include/asm-blackfin/syscall.h b/include/asm-blackfin/syscall.h
-index 9eda8b9..b5728b5 100644
---- a/include/asm-blackfin/syscall.h
-+++ b/include/asm-blackfin/syscall.h
-@@ -132,9 +132,9 @@ static inline int __xn_interrupted_p(struct pt_regs *regs)
- #define XENOMAI_SKINCALL5(id,op,a1,a2,a3,a4,a5) XENOMAI_DO_SYSCALL(5,id,op,a1,a2,a3,a4,a5)
- 
- /* uClibc does not provide pthread_atfork() for this arch; provide it
--   here. Note: let the compiler decides whether it wants to actually
--   inline this routine, i.e. do not force always_inline. */
--inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
-+   here.
-+*/
-+__attribute__((weak)) int pthread_atfork(void (*prepare)(void),
- 						void (*parent)(void),
- 						void (*child)(void))
- {
-@@ -143,7 +143,7 @@ inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
- 
- #include <errno.h>
- 
--inline __attribute__((weak)) int shm_open(const char *name,
-+__attribute__((weak)) int shm_open(const char *name,
- 					  int oflag,
- 					  mode_t mode)
- {
-@@ -151,7 +151,7 @@ inline __attribute__((weak)) int shm_open(const char *name,
- 	return -1;
- }
- 
--inline __attribute__((weak)) int shm_unlink(const char *name)
-+__attribute__((weak)) int shm_unlink(const char *name)
- {
- 	errno = ENOSYS;
- 	return -1;
--- 
-2.5.5
-
-- 
2.12.0

[Buildroot] [PATCH 3/3] xenomai: enable SMP in configuration options

[sikor6 at gmail.com]

From: Pawel Sikora <sikor6@gmail.com>

Add --enable-smp to XENOMAI_CONF_OPTS, so kernel and xenomai
userpace libs both support it.

Signed-off-by: Pawel Sikora <sikor6@gmail.com>
---
 package/xenomai/xenomai.mk | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
index 28875b944..37ec68526 100644
--- a/package/xenomai/xenomai.mk
+++ b/package/xenomai/xenomai.mk
@@ -21,7 +21,7 @@ XENOMAI_INSTALL_STAGING = YES
 XENOMAI_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-user
 XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
 
-XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
+XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install --enable-smp
 
 define XENOMAI_REMOVE_DEVFILES
 	for i in xeno-config xeno-info wrap-link.sh ; do \
-- 
2.12.0

[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[Arnout Vandecappelle]

On 20-03-17 23:40, Thomas Petazzoni wrote:
> Hello,
> 
> On Tue, 21 Mar 2017 00:33:47 +0100, sikor6 at gmail.com wrote:
>> From: Pawel Sikora <sikor6@gmail.com>
>>
>> Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> 
> Thanks a lot for looking at the Xenomai package. It hasn't been updated
> in a while.
> 
>> ---
>>  package/xenomai/xenomai.hash | 2 +-
>>  package/xenomai/xenomai.mk   | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/package/xenomai/xenomai.hash b/package/xenomai/xenomai.hash
>> index 4d74472ee..e41859343 100644
>> --- a/package/xenomai/xenomai.hash
>> +++ b/package/xenomai/xenomai.hash
>> @@ -1,2 +1,2 @@
>>  # Locally computed;
>> -sha256  b6ff723cb0f3b1c2c4e15bccfd114b248dea1b4164a0ac0e612815379ce7caf8  xenomai-2.6.4.tar.bz2
>> +sha256  4c396b4d447efd414c4d7c0894f97ef52b4ec45c87f512c14adee981a45f0e3b  xenomai-3.0.3.tar.bz2
>> diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
>> index 6e0e44163..28875b944 100644
>> --- a/package/xenomai/xenomai.mk
>> +++ b/package/xenomai/xenomai.mk
>> @@ -6,7 +6,7 @@
>>  
>>  XENOMAI_VERSION = $(call qstrip,$(BR2_PACKAGE_XENOMAI_VERSION))
>>  ifeq ($(XENOMAI_VERSION),)
>> -XENOMAI_VERSION = 2.6.4
>> +XENOMAI_VERSION = 3.0.3
> 
> My understanding was that Xenomai 3.x was significantly different from
> Xenomai 2.x. Should we support both versions? Is Xenomai 3.x now old
> enough that Xenomai 2.x is considered legacy? What problems will people
> currently using Xenomai 2.x face if we ask them to move to Xenomai 3.x?

 There are some API differences, but (at least in dual-kernel mode), it is
pretty easy to port over. I think we have lots of packages where version bumps
introduce slight behavioural changes so I think this is OK.


 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 2/3] remove: 0001-bfin-remove-inline-keyword.patch

[Arnout Vandecappelle]

On 21-03-17 00:33, sikor6 at gmail.com wrote:
> From: Pawel Sikora <sikor6@gmail.com>
> 
> Remove 0001-bfin-remove-inline-keyword.patch due to bumping
> Xenomai to version 3.0.3

 This doesn't really explain anything - it's obvious that you remove the patch,
you should explain _why_:
 - already included upstream;
 - no longer necessary (why not?);
 - doesn't apply anymore (in that case, does xenomai still build for blackfin?)
But this is an upstream patch so it's the first case. So the commit message
should just be "0001-bfin-remove-inline-keyword.patch already applied upstream".

 Since this change is related to the bump to 3.0.3, it should be squashed into
that patch, i.e. a single commit should remove this patch, bump the version to
3.0.3, and update the hash file.

 Regards,
 Arnout

> 
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> ---
>  .../xenomai/0001-bfin-remove-inline-keyword.patch  | 62 ----------------------
>  1 file changed, 62 deletions(-)
>  delete mode 100644 package/xenomai/0001-bfin-remove-inline-keyword.patch
> 
> diff --git a/package/xenomai/0001-bfin-remove-inline-keyword.patch b/package/xenomai/0001-bfin-remove-inline-keyword.patch
> deleted file mode 100644
> index 376bd21c3..000000000
> --- a/package/xenomai/0001-bfin-remove-inline-keyword.patch
> +++ /dev/null
> @@ -1,62 +0,0 @@
> -From 2a96c8bbe19a193d9ae6d0780fc274abc4df03e3 Mon Sep 17 00:00:00 2001
> -From: Romain Naour <romain.naour@gmail.com>
> -Date: Sat, 5 Nov 2016 19:09:00 +0100
> -Subject: [PATCH] bfin: remove inline keyword
> -
> -Xenomai user space tools fail to build for bfin target since it's
> -provide it's own pthread_atfork(), shm_open() and shm_unlink()
> -definition using the inline keyword and weak attribute.
> -
> -With gcc 5+ the weak attribute is discarded by the inline keyword,
> -so each symbol are global and are redefined several time while
> -linking.
> -
> -Fixes:
> -http://autobuild.buildroot.net/results/0c2/0c2e5eb4edd4f9427f61d3c9b67a12a7a0e24140
> -
> -Patch status: upstream,
> -https://git.xenomai.org/xenomai-2.6.git/commit/?id=917dcebb26ec492f276cdc3b55867aa90e01fa12
> -
> -Signed-off-by: Romain Naour <romain.naour@gmail.com>
> ----
> - include/asm-blackfin/syscall.h | 10 +++++-----
> - 1 file changed, 5 insertions(+), 5 deletions(-)
> -
> -diff --git a/include/asm-blackfin/syscall.h b/include/asm-blackfin/syscall.h
> -index 9eda8b9..b5728b5 100644
> ---- a/include/asm-blackfin/syscall.h
> -+++ b/include/asm-blackfin/syscall.h
> -@@ -132,9 +132,9 @@ static inline int __xn_interrupted_p(struct pt_regs *regs)
> - #define XENOMAI_SKINCALL5(id,op,a1,a2,a3,a4,a5) XENOMAI_DO_SYSCALL(5,id,op,a1,a2,a3,a4,a5)
> - 
> - /* uClibc does not provide pthread_atfork() for this arch; provide it
> --   here. Note: let the compiler decides whether it wants to actually
> --   inline this routine, i.e. do not force always_inline. */
> --inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
> -+   here.
> -+*/
> -+__attribute__((weak)) int pthread_atfork(void (*prepare)(void),
> - 						void (*parent)(void),
> - 						void (*child)(void))
> - {
> -@@ -143,7 +143,7 @@ inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
> - 
> - #include <errno.h>
> - 
> --inline __attribute__((weak)) int shm_open(const char *name,
> -+__attribute__((weak)) int shm_open(const char *name,
> - 					  int oflag,
> - 					  mode_t mode)
> - {
> -@@ -151,7 +151,7 @@ inline __attribute__((weak)) int shm_open(const char *name,
> - 	return -1;
> - }
> - 
> --inline __attribute__((weak)) int shm_unlink(const char *name)
> -+__attribute__((weak)) int shm_unlink(const char *name)
> - {
> - 	errno = ENOSYS;
> - 	return -1;
> --- 
> -2.5.5
> -
> 

-- 
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 3/3] xenomai: enable SMP in configuration options

[Arnout Vandecappelle]

On 21-03-17 00:33, sikor6 at gmail.com wrote:
> From: Pawel Sikora <sikor6@gmail.com>
> 
> Add --enable-smp to XENOMAI_CONF_OPTS, so kernel and xenomai
> userpace libs both support it.

 This is not good, because xenomai is still used a lot on uniprocessors as well.
Ideally, we'd check linux .config if SMP is enabled or not - but unfortunately
that's not an option since Xenomai userspace can be built without building a kernel.

 I think the only option here is to add a Config.in symbol to allow the user to
select SMP.

 Unless you can verify that enabling SMP unconditionally is not a problem, i.e.
that it doesn't give overhead (extra latency) on a uniprocessor. But then I
wonder why it would be an option in Xenomai...

 Regards,
 Arnout

> 
> Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> ---
>  package/xenomai/xenomai.mk | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> index 28875b944..37ec68526 100644
> --- a/package/xenomai/xenomai.mk
> +++ b/package/xenomai/xenomai.mk
> @@ -21,7 +21,7 @@ XENOMAI_INSTALL_STAGING = YES
>  XENOMAI_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-user
>  XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
>  
> -XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install
> +XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/ --disable-doc-install --enable-smp
>  
>  define XENOMAI_REMOVE_DEVFILES
>  	for i in xeno-config xeno-info wrap-link.sh ; do \
> 

-- 
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/3] xenomai: bump version to 3.0.3

[Thomas Petazzoni]

Hello,

On Tue, 21 Mar 2017 09:57:35 +0100, Arnout Vandecappelle wrote:

> > My understanding was that Xenomai 3.x was significantly different from
> > Xenomai 2.x. Should we support both versions? Is Xenomai 3.x now old
> > enough that Xenomai 2.x is considered legacy? What problems will people
> > currently using Xenomai 2.x face if we ask them to move to Xenomai 3.x?  
> 
>  There are some API differences, but (at least in dual-kernel mode), it is
> pretty easy to port over. I think we have lots of packages where version bumps
> introduce slight behavioural changes so I think this is OK.

OK, thanks. As long as it doesn't require people having Xenomai
applications to do a full rewrite, then I'm fine with a bump to 3.X as
opposed to supporting both 2.x and 3.x. Minor adaptations are OK, just
like is often needed when upgrading libraries, as you said.

Best regards,

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

[Buildroot] [PATCH 2/3] remove: 0001-bfin-remove-inline-keyword.patch

[Pawel Sikora]

Ok, thanks! Corrected patch:

http://lists.busybox.net/pipermail/buildroot/2017-March/187477.html




*Pozdrawiam,*
*Pawe? Sikora*

2017-03-21 10:05 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:

>
>
> On 21-03-17 00:33, sikor6 at gmail.com wrote:
> > From: Pawel Sikora <sikor6@gmail.com>
> >
> > Remove 0001-bfin-remove-inline-keyword.patch due to bumping
> > Xenomai to version 3.0.3
>
>  This doesn't really explain anything - it's obvious that you remove the
> patch,
> you should explain _why_:
>  - already included upstream;
>  - no longer necessary (why not?);
>  - doesn't apply anymore (in that case, does xenomai still build for
> blackfin?)
> But this is an upstream patch so it's the first case. So the commit message
> should just be "0001-bfin-remove-inline-keyword.patch already applied
> upstream".
>
>  Since this change is related to the bump to 3.0.3, it should be squashed
> into
> that patch, i.e. a single commit should remove this patch, bump the
> version to
> 3.0.3, and update the hash file.
>
>  Regards,
>  Arnout
>
> >
> > Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> > ---
> >  .../xenomai/0001-bfin-remove-inline-keyword.patch  | 62
> ----------------------
> >  1 file changed, 62 deletions(-)
> >  delete mode 100644 package/xenomai/0001-bfin-
> remove-inline-keyword.patch
> >
> > diff --git a/package/xenomai/0001-bfin-remove-inline-keyword.patch
> b/package/xenomai/0001-bfin-remove-inline-keyword.patch
> > deleted file mode 100644
> > index 376bd21c3..000000000
> > --- a/package/xenomai/0001-bfin-remove-inline-keyword.patch
> > +++ /dev/null
> > @@ -1,62 +0,0 @@
> > -From 2a96c8bbe19a193d9ae6d0780fc274abc4df03e3 Mon Sep 17 00:00:00 2001
> > -From: Romain Naour <romain.naour@gmail.com>
> > -Date: Sat, 5 Nov 2016 19:09:00 +0100
> > -Subject: [PATCH] bfin: remove inline keyword
> > -
> > -Xenomai user space tools fail to build for bfin target since it's
> > -provide it's own pthread_atfork(), shm_open() and shm_unlink()
> > -definition using the inline keyword and weak attribute.
> > -
> > -With gcc 5+ the weak attribute is discarded by the inline keyword,
> > -so each symbol are global and are redefined several time while
> > -linking.
> > -
> > -Fixes:
> > -http://autobuild.buildroot.net/results/0c2/
> 0c2e5eb4edd4f9427f61d3c9b67a12a7a0e24140
> > -
> > -Patch status: upstream,
> > -https://git.xenomai.org/xenomai-2.6.git/commit/?id=
> 917dcebb26ec492f276cdc3b55867aa90e01fa12
> > -
> > -Signed-off-by: Romain Naour <romain.naour@gmail.com>
> > ----
> > - include/asm-blackfin/syscall.h | 10 +++++-----
> > - 1 file changed, 5 insertions(+), 5 deletions(-)
> > -
> > -diff --git a/include/asm-blackfin/syscall.h b/include/asm-blackfin/
> syscall.h
> > -index 9eda8b9..b5728b5 100644
> > ---- a/include/asm-blackfin/syscall.h
> > -+++ b/include/asm-blackfin/syscall.h
> > -@@ -132,9 +132,9 @@ static inline int __xn_interrupted_p(struct pt_regs
> *regs)
> > - #define XENOMAI_SKINCALL5(id,op,a1,a2,a3,a4,a5)
> XENOMAI_DO_SYSCALL(5,id,op,a1,a2,a3,a4,a5)
> > -
> > - /* uClibc does not provide pthread_atfork() for this arch; provide it
> > --   here. Note: let the compiler decides whether it wants to actually
> > --   inline this routine, i.e. do not force always_inline. */
> > --inline __attribute__((weak)) int pthread_atfork(void (*prepare)(void),
> > -+   here.
> > -+*/
> > -+__attribute__((weak)) int pthread_atfork(void (*prepare)(void),
> > -                                             void (*parent)(void),
> > -                                             void (*child)(void))
> > - {
> > -@@ -143,7 +143,7 @@ inline __attribute__((weak)) int
> pthread_atfork(void (*prepare)(void),
> > -
> > - #include <errno.h>
> > -
> > --inline __attribute__((weak)) int shm_open(const char *name,
> > -+__attribute__((weak)) int shm_open(const char *name,
> > -                                       int oflag,
> > -                                       mode_t mode)
> > - {
> > -@@ -151,7 +151,7 @@ inline __attribute__((weak)) int shm_open(const
> char *name,
> > -     return -1;
> > - }
> > -
> > --inline __attribute__((weak)) int shm_unlink(const char *name)
> > -+__attribute__((weak)) int shm_unlink(const char *name)
> > - {
> > -     errno = ENOSYS;
> > -     return -1;
> > ---
> > -2.5.5
> > -
> >
>
> --
> 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/20170321/05d293ce/attachment.html>

[Buildroot] [PATCH 3/3] xenomai: enable SMP in configuration options

[Pawel Sikora]

Completely agree, corrected patch:

http://lists.busybox.net/pipermail/buildroot/2017-March/187474.html

including adding option in Config.in and checking it in xenomai.mk

Tested in runtime on Zybo Zynq-7000 with/without config enabled.

Behaves as expected on kernel with SMP:

without smp enabled:
# xeno-test
Started child 95: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ testdir=/usr/bin
+ /usr/bin/smokey --run
   0"000.000| BUG in xenomai_init(): [main] running non-SMP libraries on
SMP kernel?
              build with --enable-smp or disable check with --no-sanity

with smp enabled:
# xeno-test
Started child 95: /bin/sh /usr/bin/xeno-test-run-wrapper /usr/bin/xeno-test
+ echo 0
+ testdir=/usr/bin
+ /usr/bin/smokey --run
arith OK
bufp skipped (no kernel support)
cpu_affinity skipped (no kernel support)
iddp skipped (no kernel support)
leaks OK
net_packet_dgram skipped (no kernel support)
net_packet_raw skipped (no kernel support)
net_udp skipped (no kernel support)
...

Kind Regards,
Pawel

2017-03-21 10:08 GMT+01:00 Arnout Vandecappelle <arnout@mind.be>:

>
>
> On 21-03-17 00:33, sikor6 at gmail.com wrote:
> > From: Pawel Sikora <sikor6@gmail.com>
> >
> > Add --enable-smp to XENOMAI_CONF_OPTS, so kernel and xenomai
> > userpace libs both support it.
>
>  This is not good, because xenomai is still used a lot on uniprocessors as
> well.
> Ideally, we'd check linux .config if SMP is enabled or not - but
> unfortunately
> that's not an option since Xenomai userspace can be built without building
> a kernel.
>
>  I think the only option here is to add a Config.in symbol to allow the
> user to
> select SMP.
>
>  Unless you can verify that enabling SMP unconditionally is not a problem,
> i.e.
> that it doesn't give overhead (extra latency) on a uniprocessor. But then I
> wonder why it would be an option in Xenomai...
>
>  Regards,
>  Arnout
>
> >
> > Signed-off-by: Pawel Sikora <sikor6@gmail.com>
> > ---
> >  package/xenomai/xenomai.mk | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/package/xenomai/xenomai.mk b/package/xenomai/xenomai.mk
> > index 28875b944..37ec68526 100644
> > --- a/package/xenomai/xenomai.mk
> > +++ b/package/xenomai/xenomai.mk
> > @@ -21,7 +21,7 @@ XENOMAI_INSTALL_STAGING = YES
> >  XENOMAI_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-user
> >  XENOMAI_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-user
> >
> > -XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/
> --disable-doc-install
> > +XENOMAI_CONF_OPTS += --includedir=/usr/include/xenomai/
> --disable-doc-install --enable-smp
> >
> >  define XENOMAI_REMOVE_DEVFILES
> >       for i in xeno-config xeno-info wrap-link.sh ; do \
> >
>
> --
> 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/20170321/8f89a51f/attachment.html>

[Buildroot] [PATCH 1/3] xenomai: bump version to 3.0.3

[Pawel Sikora]

Corrected patch:
http://lists.busybox.net/pipermail/buildroot/2017-March/187477.html






*Pozdrawiam,*
*Pawe? Sikora*

2017-03-21 10:19 GMT+01:00 Thomas Petazzoni <
thomas.petazzoni@free-electrons.com>:

> Hello,
>
> On Tue, 21 Mar 2017 09:57:35 +0100, Arnout Vandecappelle wrote:
>
> > > My understanding was that Xenomai 3.x was significantly different from
> > > Xenomai 2.x. Should we support both versions? Is Xenomai 3.x now old
> > > enough that Xenomai 2.x is considered legacy? What problems will people
> > > currently using Xenomai 2.x face if we ask them to move to Xenomai 3.x?
> >
> >  There are some API differences, but (at least in dual-kernel mode), it
> is
> > pretty easy to port over. I think we have lots of packages where version
> bumps
> > introduce slight behavioural changes so I think this is OK.
>
> OK, thanks. As long as it doesn't require people having Xenomai
> applications to do a full rewrite, then I'm fine with a bump to 3.X as
> opposed to supporting both 2.x and 3.x. Minor adaptations are OK, just
> like is often needed when upgrading libraries, as you said.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20170321/928bbead/attachment.html>