Re: [Xenomai] [PATCH] gitignore: add build output for in-tree builds

2018-09-14 Thread Henning Schild 
This is the only new patch, the rest was still sitting in the
send-email directory ... sorry for the spam.

Henning

Am Fri, 14 Sep 2018 18:14:38 +0200
schrieb Henning Schild :

> This adds all build output to .gitignore. Not everybody works out of
> tree, or knows that this option exists. So let us add all build output
> to .gitignore. While this names all our binaries and has the risk of
> getting out of sync, it at least makes "git status" human readable
> again.
> 
> Signed-off-by: Henning Schild 
> ---
>  .gitignore | 67
> ++ 1 file
> changed, 67 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index b1d682032..a054a65af 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,3 +15,70 @@ config/missing
>  configure
>  aclocal.m4
>  autom4te.cache
> +Makefile
> +.deps
> +config.log
> +config.status
> +include/stamp-h1
> +include/xeno_config.h
> +libtool
> +scripts/xeno
> +scripts/xeno-config
> +utils/net/rtnet
> +utils/net/rtnet.conf
> +*.a
> +*.o
> +*.la
> +*.lo
> +.libs
> +.dirstamp
> +demo/alchemy/altency
> +demo/alchemy/cobalt/cross-link
> +demo/posix/cobalt/bufp-label
> +demo/posix/cobalt/bufp-readwrite
> +demo/posix/cobalt/can_rtt
> +demo/posix/cobalt/eth_p_all
> +demo/posix/cobalt/gpiopwm
> +demo/posix/cobalt/iddp-label
> +demo/posix/cobalt/iddp-sendrecv
> +demo/posix/cobalt/xddp-echo
> +demo/posix/cobalt/xddp-label
> +demo/posix/cobalt/xddp-stream
> +demo/posix/cyclictest/cyclictest
> +lib/boilerplate/config-dump.h
> +lib/boilerplate/git-stamp.h
> +lib/boilerplate/version
> +testsuite/clocktest/clocktest
> +testsuite/gpiotest/gpiotest
> +testsuite/latency/latency
> +testsuite/smokey/net_common/smokey_net_server
> +testsuite/smokey/smokey
> +testsuite/spitest/spitest
> +testsuite/switchtest/switchtest
> +testsuite/xeno-test/xeno-test
> +testsuite/xeno-test/xeno-test-run
> +utils/analogy/analogy_calibrate
> +utils/analogy/analogy_config
> +utils/analogy/cmd_bits
> +utils/analogy/cmd_read
> +utils/analogy/cmd_write
> +utils/analogy/insn_bits
> +utils/analogy/insn_read
> +utils/analogy/insn_write
> +utils/analogy/wf_generate
> +utils/autotune/autotune
> +utils/can/rtcanconfig
> +utils/can/rtcanrecv
> +utils/can/rtcansend
> +utils/corectl/corectl
> +utils/hdb/hdb
> +utils/net/nomaccfg
> +utils/net/rtcfg
> +utils/net/rtifconfig
> +utils/net/rtiwconfig
> +utils/net/rtping
> +utils/net/rtroute
> +utils/net/tdmacfg
> +utils/ps/rtps
> +utils/slackspot/slackspot
> +testsuite/smokey/dlopen/dlopentest


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

[Xenomai] [PATCHv2 1/4] cobalt/x86: add support for eager fpu handling

2018-09-14 Thread Henning Schild 
Upstream 4.14 switched to purely eager fpu switching. That was
backported to 4.4 and 4.9. This commit makes cobalt able to deal whith
the changed kernel behaviour.
This commit takes care of 4.9 to begin with.

Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
implementations. The new implementation is much simpler than the old
one. We basically only deal with the odd case where Xenomai preempts
Linux in a kernel-fpu context.
In a regular Linux that can never happen and if it happens we need to
make sure to get things into a consistent state. We have to make
"current" as not owning the fpu anymore and allow others to use
in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the
rest.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/thread.h |  8 ++-
 .../arch/x86/include/asm/xenomai/wrappers.h   |  5 ++
 kernel/cobalt/arch/x86/thread.c   | 69 ++-
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index f174a82c0..0c5c4da9c 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
 typedef union thread_xstate x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.state)
@@ -31,6 +32,7 @@ typedef union thread_xstate x86_fpustate;
 typedef union fpregs_state x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.active_state)
 #endif
+#endif
 
 struct xnarchtcb {
struct xntcb core;
@@ -40,10 +42,14 @@ struct xnarchtcb {
unsigned long ip;
unsigned long *ipp;
 #endif  
+#ifdef IPIPE_X86_FPU_EAGER
+   struct fpu *kfpu;
+#else
x86_fpustate *fpup;
-   unsigned int root_kfpu: 1;
unsigned int root_used_math: 1;
x86_fpustate *kfpu_state;
+#endif
+   unsigned int root_kfpu: 1;
struct {
unsigned long ip;
unsigned long ax;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 5f9cff3c9..00f0aaae5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -24,6 +24,11 @@
 #define __get_user_inatomic __get_user
 #define __put_user_inatomic __put_user
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 7fb136300..18cf636e5 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -28,9 +28,13 @@
 
 static struct kmem_cache *xstate_cache;
 
+#ifdef IPIPE_X86_FPU_EAGER
+#define fpu_kernel_xstate_size sizeof(struct fpu)
+#else
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 #define fpu_kernel_xstate_size xstate_size
 #endif
+#endif /* IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
 #define cpu_has_xmm boot_cpu_has(X86_FEATURE_XMM)
@@ -199,14 +203,17 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
struct mm_struct *prev_mm, *next_mm;
 
prev = out_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
if (x86_fpregs_active(prev))
/*
 * __switch_to will try and use __unlazy_fpu, so we
 * need to clear the ts bit.
 */
clts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
next = in_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
next->thread.fpu.counter = 0;
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(3,13,0)
@@ -214,6 +221,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread 
*in)
 #else
next->fpu_counter = 0;
 #endif
+#endif /* ! IPIPE_X86_FPU_EAGER */
prev_mm = out_tcb->core.active_mm;
next_mm = in_tcb->core.mm;
if (next_mm == NULL) {
@@ -245,9 +253,13 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
switch_to(prev, next, last);
 #endif /* LINUX_VERSION_CODE >= 4.8 */
 
+#ifndef IPIPE_X86_FPU_EAGER
stts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
+#ifndef IPIPE_X86_FPU_EAGER
+
 #ifdef CONFIG_X86_64
 #define XSAVE_PREFIX   "0x48,"
 #define XSAVE_SUFFIX   "q"
@@ -359,11 +371,21 @@ int xnarch_handle_fpu_fault(struct xnthread *from,
 
return 1;
 }
+#else /* IPIPE_X86_FPU_EAGER */
+
+int xnarch_handle_fpu_fault(struct xnthread *from,
+   struct xnthread *to, struct ipipe_trap_data *d)
+{
+   // in eager mode there are no such faults
+   BUG_ON(1);
+}
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #define current_task_used_kfpu()

[Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

2018-09-14 Thread Henning Schild 
Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and 4.9
series similar changes where backported.
So fpu is eager for those versions. That simplifies things a lot and we can
drop several changes from the IPIPE patch.
On the Xenomai side the only thing we still have to care about is the
kernel fpu state when we interrupt an in kernel fpu user. But we do that
explicit and can drop the indirection active_(fp)state.

This patch basically drops most of the fpu specifics from the ipipe
patch.

This patch applies on ipipe-4.9.y and it has to be followed by a merge with
>= 4.9.109. Cobalt will not compile if you are already eager and still
4.9.108

Signed-off-by: Henning Schild 
---
 arch/x86/include/asm/fpu/internal.h | 30 -
 arch/x86/include/asm/fpu/types.h| 12 
 arch/x86/kernel/fpu/core.c  | 17 ++--
 arch/x86/kernel/fpu/init.c  |  5 +
 4 files changed, 15 insertions(+), 49 deletions(-)

diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index 35ca184e83e1..6bdceba90f17 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct fregs_state 
__user *fx)
return user_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
 }
 
-#ifdef CONFIG_IPIPE
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return fpu->active_state;
-}
-#else
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return >state;
-}
-#endif
-
 static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 {
if (IS_ENABLED(CONFIG_X86_32))
-   asm volatile( "fxsave %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
-   asm volatile("fxsaveq %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
else {
/* Using "rex64; fxsave %0" is broken because, if the memory
 * operand uses any extended registers for addressing, a second
@@ -231,8 +218,8 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 * registers.
 */
asm volatile( "rex64/fxsave (%[fx])"
- : "=m" (active_fpstate(fpu)->fxsave)
- : [fx] "R" (_fpstate(fpu)->fxsave));
+ : "=m" (fpu->state.fxsave)
+ : [fx] "R" (>state.fxsave));
}
 }
 
@@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct xregs_state 
__user *buf, u64 mask)
 static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 {
if (likely(use_xsave())) {
-   copy_xregs_to_kernel(_fpstate(fpu)->xsave);
+   copy_xregs_to_kernel(>state.xsave);
return 1;
}
 
@@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 * Legacy FPU register saving, FNSAVE always clears FPU registers,
 * so we have to mark them inactive:
 */
-   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" 
(active_fpstate(fpu)->fsave));
+   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" (fpu->state.fsave));
 
return 0;
 }
@@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
 * If the task has used the math, pre-load the FPU on xsave processors
 * or if the past 5 consecutive context-switches used math.
 */
-   fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
- static_cpu_has(X86_FEATURE_FPU) &&
+   fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
  new_fpu->fpstate_active &&
  (use_eager_fpu() || new_fpu->counter > 5);
 
@@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
  */
 static inline void switch_fpu_finish(struct fpu *new_fpu, fpu_switch_t 
fpu_switch)
 {
-   if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
+   if (fpu_switch.preload)
copy_kernel_to_fpregs(_fpu->state);
 }
 
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 497c551469ec..48df486b02f9 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -332,18 +332,6 @@ struct fpu {
 * deal with bursty apps that only use the FPU for a short time:
 */
unsigned char   counter;
-
-#ifdef CONFIG_IPIPE
-   /*
-* @active_state
-*
-* An indirection pointer to reach the active state context
-* for the task.  This is used by co-kernels for dealing with
-*

[Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

2018-09-14 Thread Henning Schild 
4.14 is always eager, unfortunately we will need a few ifdefs inside the
eager fpu support as well.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
 kernel/cobalt/arch/x86/thread.c   | 21 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index a47730106..a4cc368a5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -32,6 +32,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 18cf636e5..2668ce274 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
 #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
 #endif
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
@@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct task_struct *t)
 #define x86_xstate_alignment   __alignof__(union fpregs_state)
 
 #endif
+#else /* IPIPE_X86_FPU_EAGER */
+#define x86_xstate_alignment   __alignof__(union fpregs_state)
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
 /*
@@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
// save fpregs from in-kernel use
copy_fpregs_to_fpstate(rootcb->kfpu);
kernel_fpu_enable();
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+   // restore current's fpregs
+   __cpu_invalidate_fpregs_state();
+   switch_fpu_finish(>thread.fpu, smp_processor_id());
+#else
// mark current thread as not owning the FPU anymore
if (>thread.fpu.fpstate_active)
fpregs_deactivate(>thread.fpu);
+#endif
 }
 
 void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
@@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread *thread)
 #else /* IPIPE_X86_FPU_EAGER */
/* XNFPU is always set */
xnthread_set_state(thread, XNFPU);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
fpu__activate_fpstate_read(>thread.fpu);
+#else
+   fpu__initialize(>thread.fpu);
+#endif
 #endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
@@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
xstate_cache = kmem_cache_create("cobalt_x86_xstate",
 fpu_kernel_xstate_size,
 x86_xstate_alignment,
-SLAB_NOTRACK, NULL);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
+SLAB_NOTRACK,
+#else
+0,
+#endif
+NULL);
if (xstate_cache == NULL)
return -ENOMEM;
 
-- 
2.19.0


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

[Xenomai] [PATCH] gitignore: add build output for in-tree builds

2018-09-14 Thread Henning Schild 
This adds all build output to .gitignore. Not everybody works out of
tree, or knows that this option exists. So let us add all build output
to .gitignore. While this names all our binaries and has the risk of
getting out of sync, it at least makes "git status" human readable again.

Signed-off-by: Henning Schild 
---
 .gitignore | 67 ++
 1 file changed, 67 insertions(+)

diff --git a/.gitignore b/.gitignore
index b1d682032..a054a65af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,70 @@ config/missing
 configure
 aclocal.m4
 autom4te.cache
+Makefile
+.deps
+config.log
+config.status
+include/stamp-h1
+include/xeno_config.h
+libtool
+scripts/xeno
+scripts/xeno-config
+utils/net/rtnet
+utils/net/rtnet.conf
+*.a
+*.o
+*.la
+*.lo
+.libs
+.dirstamp
+demo/alchemy/altency
+demo/alchemy/cobalt/cross-link
+demo/posix/cobalt/bufp-label
+demo/posix/cobalt/bufp-readwrite
+demo/posix/cobalt/can_rtt
+demo/posix/cobalt/eth_p_all
+demo/posix/cobalt/gpiopwm
+demo/posix/cobalt/iddp-label
+demo/posix/cobalt/iddp-sendrecv
+demo/posix/cobalt/xddp-echo
+demo/posix/cobalt/xddp-label
+demo/posix/cobalt/xddp-stream
+demo/posix/cyclictest/cyclictest
+lib/boilerplate/config-dump.h
+lib/boilerplate/git-stamp.h
+lib/boilerplate/version
+testsuite/clocktest/clocktest
+testsuite/gpiotest/gpiotest
+testsuite/latency/latency
+testsuite/smokey/net_common/smokey_net_server
+testsuite/smokey/smokey
+testsuite/spitest/spitest
+testsuite/switchtest/switchtest
+testsuite/xeno-test/xeno-test
+testsuite/xeno-test/xeno-test-run
+utils/analogy/analogy_calibrate
+utils/analogy/analogy_config
+utils/analogy/cmd_bits
+utils/analogy/cmd_read
+utils/analogy/cmd_write
+utils/analogy/insn_bits
+utils/analogy/insn_read
+utils/analogy/insn_write
+utils/analogy/wf_generate
+utils/autotune/autotune
+utils/can/rtcanconfig
+utils/can/rtcanrecv
+utils/can/rtcansend
+utils/corectl/corectl
+utils/hdb/hdb
+utils/net/nomaccfg
+utils/net/rtcfg
+utils/net/rtifconfig
+utils/net/rtiwconfig
+utils/net/rtping
+utils/net/rtroute
+utils/net/tdmacfg
+utils/ps/rtps
+utils/slackspot/slackspot
+testsuite/smokey/dlopen/dlopentest
-- 
2.19.0


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

[Xenomai] [PATCHv2 2/4] cobalt/x86: add ipipe-4.4 eager fpu support

2018-09-14 Thread Henning Schild 
Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER
accordingly.

Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 00f0aaae5..a47730106 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -28,6 +28,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,4,137) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
-- 
2.19.0


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

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Lange Norbert 


>>> Norbert, I have followed your emails and your project. You did a good job,
>>> but I don't agree with your approach. My points are:
>>>
>>> - You are trying to convert Xenomai a CMake project and this probably will
>>> not happen because Upstream is very happy with the autotools. I don't like
>>> to touch anything from upstream. Maybe some patch, but incorporated in
>>> Upstream.
>>
>> Sorry, that's nonsense, never thought about building Xenomai with CMake.

> Sorry, you are right. It seemed that you tried to generated the config files
> generated usually with a cmake project.

I do, but that's not happening during configuration or installation. I created
the config templates with CMake as thast alot less error-prone and easier to 
maintain

>>> - I would prefer follow the Upstream guidelines that recommends use xeno-
>>> config to obtain the needed parameters to build your application.
>>> So, any build tool should use xeno-config (maintained by upstream) that
>>> provide the correct flags or whatever to build your application.
>>
>> I tried multiple approaches, using xeno-config fell out shortly.
>> -   it's (logically) an target "executable".
>> That imposes problems with CMake's normal search for those,
>> not to mention CI when your builder works in a partition with noexec.
>> I would want to use config-files directly or with a host-executable,
>> like pkg-config uses .pc files.
>
> I have not found any important problem with the xeno-config generate info or 
> any
> problem with cmake. I agree with you that you need to exec an script to 
> generate
> the info and it could have problems with partitions with noexec, etc.

Well, I did find problems if you eg. create a "buildroot" and then move it.

>> -   I need to extract all information and not just flags for ONE 
>> configuration
>
> I don't extract the information for one configuration. I extract ALL the 
> modules
> installed.

yes, and xeno-config was not conceived for that.

>> That’s the most important issue, I need the "building blocks" of the 
>>command
>> line, not ONE commandline. This means you need to know xeno-config
>> and its flags precisely and figure out how to dissect multiple outputs
>> in those "building blocks".
>> Fragile and not forwards-compatible.
>
> I don't agree. xeno-config is quite stable and well maintained. And it give 
> you
> the information that Upstream want that YOU use.

figuring out the arguments and parsing them from within CMake is what I meant 
with fragile
and not forwards-compatible.
If you have a project with Xenomai3 and a FindXenomai script,
then you might have to update your code just to be able to use a future
version. like for example if the linking order changed, which I suppose you 
aren't
deducing but use a fixed order.

>> Whats left is two variants:
>>
>> FindXenomai - this would be placed in your project or up streamed in CMake.
>> Uses CMake functions to guess the paths, this might be hard to do with some 
>> libdir / includedir
>> Configurations and would need to be updated independently of Xenomai.
>
> this is one way. Currently it just works.

It works for a couple projects you are using.

>> CMake Config files - you place those in /cmake/xenomai.
>> Those can be generated by config/install_cmakeconfig.sh from the repo (use 
>> same arguments as when configuring CMake).
>> The previously mentioned patchset adds those files to Xenomai and does this 
>> automatically when installing (using the autotools system).
>> Upstreaming in Xenomai would make everything hassle-free and 
>> forwards-compatible (the config files would always match the version).
>>
>> The downside is of course that this would then be a burden to the Xenomai 
>> devs, but it should not need any changes outside of structural changes.
>> At which point someone will have to adapt CMake integration, however its 
>> done - I would prefer it to be done just once
>>
>>
>> The repo contains other changes, attempting to sanitize the bootstrapping 
>> methods,
>> Without those the provided examples might not work (only the upstream 
>> bootstrapping method will work).
>> I hope atleast those can be upstreamed.
>
> So, maybe that config files generated by the autotools, are to me the best
> solution. Then, the responsible of compile and install xenomai in a system
> will generate the config files to use it.

the config files are not generated from scratch but have placeholders,
the same placeholders xeno-config has. That's using the information
right from the source =)

> But for this solution you need that Jan or Phillipe accept that and maintain
> that.

Yep. I have to start somewhere though.

> And looking your code and I would prefer a more simple way without modules
> and simple, just fill some config vars. Because then it could be easy to 
> maintain.

The repo deals with multiple issues, the config stuff is rather simple and 
straightforward.
not sure what you mean with modules? if you

Re: [Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

2018-09-14 Thread Henning Schild 
All three kernels are tested now. I addressed comments from the first
review. Unfortunately i did not find a nice split to reduce the ifdef
hell we are in here.

I guess once we drop lazy fpu, most of it will go away.

Henning

Am Fri, 14 Sep 2018 17:10:18 +0200
schrieb Henning Schild :

> 4.14 is always eager, unfortunately we will need a few ifdefs inside
> the eager fpu support as well.
> 
> Signed-off-by: Henning Schild 
> ---
>  .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
>  kernel/cobalt/arch/x86/thread.c   | 21
> ++- 2 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h index
> a47730106..a4cc368a5 100644 ---
> a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h +++
> b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h @@ -32,6
> +32,10 @@ LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
>  #define IPIPE_X86_FPU_EAGER
>  #endif
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> +#define IPIPE_X86_FPU_EAGER
> +#endif
> +
>  
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
>  #include 
> diff --git a/kernel/cobalt/arch/x86/thread.c
> b/kernel/cobalt/arch/x86/thread.c index 18cf636e5..2668ce274 100644
> --- a/kernel/cobalt/arch/x86/thread.c
> +++ b/kernel/cobalt/arch/x86/thread.c
> @@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
>  #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
>  #endif
>  
> +#ifndef IPIPE_X86_FPU_EAGER
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
>  #include 
>  #include 
> @@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct
> task_struct *t) #define x86_xstate_alignment
> __alignof__(union fpregs_state) 
>  #endif
> +#else /* IPIPE_X86_FPU_EAGER */
> +#define x86_xstate_alignment __alignof__(union
> fpregs_state) +#endif /* ! IPIPE_X86_FPU_EAGER */
>  
>  #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
>  /*
> @@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
>   // save fpregs from in-kernel use
>   copy_fpregs_to_fpstate(rootcb->kfpu);
>   kernel_fpu_enable();
> +#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
> + // restore current's fpregs
> + __cpu_invalidate_fpregs_state();
> + switch_fpu_finish(>thread.fpu, smp_processor_id());
> +#else
>   // mark current thread as not owning the FPU anymore
>   if (>thread.fpu.fpstate_active)
>   fpregs_deactivate(>thread.fpu);
> +#endif
>  }
>  
>  void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
> @@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread
> *thread) #else /* IPIPE_X86_FPU_EAGER */
>   /* XNFPU is always set */
>   xnthread_set_state(thread, XNFPU);
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
>   fpu__activate_fpstate_read(>thread.fpu);
> +#else
> + fpu__initialize(>thread.fpu);
> +#endif
>  #endif /* ! IPIPE_X86_FPU_EAGER */
>  }
>  
> @@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
>   xstate_cache = kmem_cache_create("cobalt_x86_xstate",
>fpu_kernel_xstate_size,
>x86_xstate_alignment,
> -  SLAB_NOTRACK, NULL);
> +#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
> +  SLAB_NOTRACK,
> +#else
> +  0,
> +#endif
> +  NULL);
>   if (xstate_cache == NULL)
>   return -ENOMEM;
>  



-- 
Siemens AG
Corporate Technology
CT RDA IOT SES-DE
Otto-Hahn-Ring 6
81739 Muenchen, Germany
Mobile: +49 172 8378927
mailto: henning.sch...@siemens.com

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

Re: [Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

2018-09-14 Thread Henning Schild 
Change to v1:
  removed whitespace changes and changed commit message

Am Fri, 14 Sep 2018 17:10:15 +0200
schrieb Henning Schild :

> Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and
> 4.9 series similar changes where backported.
> So fpu is eager for those versions. That simplifies things a lot and
> we can drop several changes from the IPIPE patch.
> On the Xenomai side the only thing we still have to care about is the
> kernel fpu state when we interrupt an in kernel fpu user. But we do
> that explicit and can drop the indirection active_(fp)state.
> 
> This patch basically drops most of the fpu specifics from the ipipe
> patch.
> 
> This patch applies on ipipe-4.9.y and it has to be followed by a
> merge with
> >= 4.9.109. Cobalt will not compile if you are already eager and
> >still  
> 4.9.108
> 
> Signed-off-by: Henning Schild 
> ---
>  arch/x86/include/asm/fpu/internal.h | 30
> - arch/x86/include/asm/fpu/types.h|
> 12  arch/x86/kernel/fpu/core.c  | 17
> ++-- arch/x86/kernel/fpu/init.c  |  5 +
>  4 files changed, 15 insertions(+), 49 deletions(-)
> 
> diff --git a/arch/x86/include/asm/fpu/internal.h
> b/arch/x86/include/asm/fpu/internal.h index
> 35ca184e83e1..6bdceba90f17 100644 ---
> a/arch/x86/include/asm/fpu/internal.h +++
> b/arch/x86/include/asm/fpu/internal.h @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct
> fregs_state __user *fx) return user_insn(frstor %[fx], "=m" (*fx),
> [fx] "m" (*fx)); }
>  
> -#ifdef CONFIG_IPIPE
> -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> -{
> - return fpu->active_state;
> -}
> -#else
> -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> -{
> - return >state;
> -}
> -#endif
> -
>  static inline void copy_fxregs_to_kernel(struct fpu *fpu)
>  {
>   if (IS_ENABLED(CONFIG_X86_32))
> - asm volatile( "fxsave %[fx]" : [fx]
> "=m" (active_fpstate(fpu)->fxsave));
> + asm volatile( "fxsave %[fx]" : [fx]
> "=m" (fpu->state.fxsave)); else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
> - asm volatile("fxsaveq %[fx]" : [fx]
> "=m" (active_fpstate(fpu)->fxsave));
> + asm volatile("fxsaveq %[fx]" : [fx]
> "=m" (fpu->state.fxsave)); else {
>   /* Using "rex64; fxsave %0" is broken because, if
> the memory
>* operand uses any extended registers for
> addressing, a second @@ -231,8 +218,8 @@ static inline void
> copy_fxregs_to_kernel(struct fpu *fpu)
>* registers.
>*/
>   asm volatile( "rex64/fxsave (%[fx])"
> -   : "=m" (active_fpstate(fpu)->fxsave)
> -   : [fx]
> "R" (_fpstate(fpu)->fxsave));
> + : "=m" (fpu->state.fxsave)
> + : [fx] "R" (>state.fxsave));
>   }
>  }
>  
> @@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct
> xregs_state __user *buf, u64 mask) static inline int
> copy_fpregs_to_fpstate(struct fpu *fpu) {
>   if (likely(use_xsave())) {
> - copy_xregs_to_kernel(_fpstate(fpu)->xsave);
> + copy_xregs_to_kernel(>state.xsave);
>   return 1;
>   }
>  
> @@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct
> fpu *fpu)
>* Legacy FPU register saving, FNSAVE always clears FPU
> registers,
>* so we have to mark them inactive:
>*/
> - asm volatile("fnsave %[fp]; fwait" : [fp]
> "=m" (active_fpstate(fpu)->fsave));
> + asm volatile("fnsave %[fp]; fwait" : [fp]
> "=m" (fpu->state.fsave)); 
>   return 0;
>  }
> @@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> fpu *new_fpu, int cpu)
>* If the task has used the math, pre-load the FPU on xsave
> processors
>* or if the past 5 consecutive context-switches used math.
>*/
> - fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
> -   static_cpu_has(X86_FEATURE_FPU) &&
> + fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
> new_fpu->fpstate_active &&
> (use_eager_fpu() || new_fpu->counter > 5);
>  
> @@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> fpu *new_fpu, int cpu) */
>  static inline void switch_fpu_finish(struct fpu *new_fpu,
> fpu_switch_t fpu_switch) {
> - if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
> + if (fpu_switch.preload)
>   copy_kernel_to_fpregs(_fpu->state);
>  }
>  
> diff --git a/arch/x86/include/asm/fpu/types.h
> b/arch/x86/include/asm/fpu/types.h index 497c551469ec..48df486b02f9
> 100644 --- a/arch/x86/include/asm/fpu/types.h
> +++ b/arch/x86/include/asm/fpu/types.h
> @@ -332,18 +332,6 @@ struct fpu {
>* deal with bursty apps that only use the FPU for a short
> time: */
>

[Xenomai] [PATCHv2 2/4] cobalt/x86: add ipipe-4.4 eager fpu support

2018-09-14 Thread Henning Schild 
Linux 4.4.138 switched to eager fpu, set IPIPE_X86_FPU_EAGER
accordingly.

Signed-off-by: Henning Schild 
---
 kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 00f0aaae5..a47730106 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -28,6 +28,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,4,137) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
-- 
2.19.0


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

[Xenomai] [PATCHv2 3/4] cobalt: fixup for kernel 4.14+

2018-09-14 Thread Henning Schild 
Signed-off-by: Henning Schild 
---
 kernel/cobalt/include/asm-generic/xenomai/syscall.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/cobalt/include/asm-generic/xenomai/syscall.h 
b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
index f11ade8e7..3873fa634 100644
--- a/kernel/cobalt/include/asm-generic/xenomai/syscall.h
+++ b/kernel/cobalt/include/asm-generic/xenomai/syscall.h
@@ -20,7 +20,12 @@
 #define _COBALT_ASM_GENERIC_SYSCALL_H
 
 #include 
+#include 
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
 #include 
+#else
+#include 
+#endif
 #include 
 #include 
 #include 
-- 
2.19.0


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

[Xenomai] [PATCHv2 4/4] cobalt/x86: add ipipe-4.14 eager fpu support

2018-09-14 Thread Henning Schild 
4.14 is always eager, unfortunately we will need a few ifdefs inside the
eager fpu support as well.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/wrappers.h   |  4 
 kernel/cobalt/arch/x86/thread.c   | 21 ++-
 2 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index a47730106..a4cc368a5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -32,6 +32,10 @@
 LINUX_VERSION_CODE < KERNEL_VERSION(4,5,0)
 #define IPIPE_X86_FPU_EAGER
 #endif
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 18cf636e5..2668ce274 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -42,6 +42,7 @@ static struct kmem_cache *xstate_cache;
 #define cpu_has_xsave boot_cpu_has(X86_FEATURE_XSAVE)
 #endif
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
@@ -72,6 +73,9 @@ static inline void x86_fpregs_activate(struct task_struct *t)
 #define x86_xstate_alignment   __alignof__(union fpregs_state)
 
 #endif
+#else /* IPIPE_X86_FPU_EAGER */
+#define x86_xstate_alignment   __alignof__(union fpregs_state)
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,8,0)
 /*
@@ -465,9 +469,15 @@ void xnarch_leave_root(struct xnthread *root)
// save fpregs from in-kernel use
copy_fpregs_to_fpstate(rootcb->kfpu);
kernel_fpu_enable();
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(4,14,0)
+   // restore current's fpregs
+   __cpu_invalidate_fpregs_state();
+   switch_fpu_finish(>thread.fpu, smp_processor_id());
+#else
// mark current thread as not owning the FPU anymore
if (>thread.fpu.fpstate_active)
fpregs_deactivate(>thread.fpu);
+#endif
 }
 
 void xnarch_switch_fpu(struct xnthread *from, struct xnthread *to)
@@ -528,7 +538,11 @@ void xnarch_init_shadow_tcb(struct xnthread *thread)
 #else /* IPIPE_X86_FPU_EAGER */
/* XNFPU is always set */
xnthread_set_state(thread, XNFPU);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
fpu__activate_fpstate_read(>thread.fpu);
+#else
+   fpu__initialize(>thread.fpu);
+#endif
 #endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
@@ -537,7 +551,12 @@ int mach_x86_thread_init(void)
xstate_cache = kmem_cache_create("cobalt_x86_xstate",
 fpu_kernel_xstate_size,
 x86_xstate_alignment,
-SLAB_NOTRACK, NULL);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(4,14,0)
+SLAB_NOTRACK,
+#else
+0,
+#endif
+NULL);
if (xstate_cache == NULL)
return -ENOMEM;
 
-- 
2.19.0


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

[Xenomai] [IPIPE] [PATCHv2] x86: make fpu switching eager

2018-09-14 Thread Henning Schild 
Linux 4.14 dropped support for lazy fpu switching and in the 4.4 and 4.9
series similar changes where backported.
So fpu is eager for those versions. That simplifies things a lot and we can
drop several changes from the IPIPE patch.
On the Xenomai side the only thing we still have to care about is the
kernel fpu state when we interrupt an in kernel fpu user. But we do that
explicit and can drop the indirection active_(fp)state.

This patch basically drops most of the fpu specifics from the ipipe
patch.

This patch applies on ipipe-4.9.y and it has to be followed by a merge with
>= 4.9.109. Cobalt will not compile if you are already eager and still
4.9.108

Signed-off-by: Henning Schild 
---
 arch/x86/include/asm/fpu/internal.h | 30 -
 arch/x86/include/asm/fpu/types.h| 12 
 arch/x86/kernel/fpu/core.c  | 17 ++--
 arch/x86/kernel/fpu/init.c  |  5 +
 4 files changed, 15 insertions(+), 49 deletions(-)

diff --git a/arch/x86/include/asm/fpu/internal.h 
b/arch/x86/include/asm/fpu/internal.h
index 35ca184e83e1..6bdceba90f17 100644
--- a/arch/x86/include/asm/fpu/internal.h
+++ b/arch/x86/include/asm/fpu/internal.h
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct fregs_state 
__user *fx)
return user_insn(frstor %[fx], "=m" (*fx), [fx] "m" (*fx));
 }
 
-#ifdef CONFIG_IPIPE
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return fpu->active_state;
-}
-#else
-static inline union fpregs_state *active_fpstate(struct fpu *fpu)
-{
-   return >state;
-}
-#endif
-
 static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 {
if (IS_ENABLED(CONFIG_X86_32))
-   asm volatile( "fxsave %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile( "fxsave %[fx]" : [fx] "=m" (fpu->state.fxsave));
else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
-   asm volatile("fxsaveq %[fx]" : [fx] "=m" 
(active_fpstate(fpu)->fxsave));
+   asm volatile("fxsaveq %[fx]" : [fx] "=m" (fpu->state.fxsave));
else {
/* Using "rex64; fxsave %0" is broken because, if the memory
 * operand uses any extended registers for addressing, a second
@@ -231,8 +218,8 @@ static inline void copy_fxregs_to_kernel(struct fpu *fpu)
 * registers.
 */
asm volatile( "rex64/fxsave (%[fx])"
- : "=m" (active_fpstate(fpu)->fxsave)
- : [fx] "R" (_fpstate(fpu)->fxsave));
+ : "=m" (fpu->state.fxsave)
+ : [fx] "R" (>state.fxsave));
}
 }
 
@@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct xregs_state 
__user *buf, u64 mask)
 static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 {
if (likely(use_xsave())) {
-   copy_xregs_to_kernel(_fpstate(fpu)->xsave);
+   copy_xregs_to_kernel(>state.xsave);
return 1;
}
 
@@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct fpu *fpu)
 * Legacy FPU register saving, FNSAVE always clears FPU registers,
 * so we have to mark them inactive:
 */
-   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" 
(active_fpstate(fpu)->fsave));
+   asm volatile("fnsave %[fp]; fwait" : [fp] "=m" (fpu->state.fsave));
 
return 0;
 }
@@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
 * If the task has used the math, pre-load the FPU on xsave processors
 * or if the past 5 consecutive context-switches used math.
 */
-   fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
- static_cpu_has(X86_FEATURE_FPU) &&
+   fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
  new_fpu->fpstate_active &&
  (use_eager_fpu() || new_fpu->counter > 5);
 
@@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct fpu 
*new_fpu, int cpu)
  */
 static inline void switch_fpu_finish(struct fpu *new_fpu, fpu_switch_t 
fpu_switch)
 {
-   if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
+   if (fpu_switch.preload)
copy_kernel_to_fpregs(_fpu->state);
 }
 
diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h
index 497c551469ec..48df486b02f9 100644
--- a/arch/x86/include/asm/fpu/types.h
+++ b/arch/x86/include/asm/fpu/types.h
@@ -332,18 +332,6 @@ struct fpu {
 * deal with bursty apps that only use the FPU for a short time:
 */
unsigned char   counter;
-
-#ifdef CONFIG_IPIPE
-   /*
-* @active_state
-*
-* An indirection pointer to reach the active state context
-* for the task.  This is used by co-kernels for dealing with
-*

[Xenomai] [PATCHv2 1/4] cobalt/x86: add support for eager fpu handling

2018-09-14 Thread Henning Schild 
Upstream 4.14 switched to purely eager fpu switching. That was
backported to 4.4 and 4.9. This commit makes cobalt able to deal whith
the changed kernel behaviour.
This commit takes care of 4.9 to begin with.

Introduce IPIPE_X86_FPU_EAGER to switch between the new and the old
implementations. The new implementation is much simpler than the old
one. We basically only deal with the odd case where Xenomai preempts
Linux in a kernel-fpu context.
In a regular Linux that can never happen and if it happens we need to
make sure to get things into a consistent state. We have to make
"current" as not owning the fpu anymore and allow others to use
in-kernel fpu (kernel_fpu_enable). __switch_to from Linux will do the
rest.

Signed-off-by: Henning Schild 
---
 .../arch/x86/include/asm/xenomai/thread.h |  8 ++-
 .../arch/x86/include/asm/xenomai/wrappers.h   |  5 ++
 kernel/cobalt/arch/x86/thread.c   | 69 ++-
 3 files changed, 79 insertions(+), 3 deletions(-)

diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
index f174a82c0..0c5c4da9c 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/thread.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,4,0)
 typedef union thread_xstate x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.state)
@@ -31,6 +32,7 @@ typedef union thread_xstate x86_fpustate;
 typedef union fpregs_state x86_fpustate;
 #define x86_fpustate_ptr(t) ((t)->fpu.active_state)
 #endif
+#endif
 
 struct xnarchtcb {
struct xntcb core;
@@ -40,10 +42,14 @@ struct xnarchtcb {
unsigned long ip;
unsigned long *ipp;
 #endif  
+#ifdef IPIPE_X86_FPU_EAGER
+   struct fpu *kfpu;
+#else
x86_fpustate *fpup;
-   unsigned int root_kfpu: 1;
unsigned int root_used_math: 1;
x86_fpustate *kfpu_state;
+#endif
+   unsigned int root_kfpu: 1;
struct {
unsigned long ip;
unsigned long ax;
diff --git a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h 
b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
index 5f9cff3c9..00f0aaae5 100644
--- a/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
+++ b/kernel/cobalt/arch/x86/include/asm/xenomai/wrappers.h
@@ -24,6 +24,11 @@
 #define __get_user_inatomic __get_user
 #define __put_user_inatomic __put_user
 
+#if LINUX_VERSION_CODE > KERNEL_VERSION(4,9,108) && \
+LINUX_VERSION_CODE < KERNEL_VERSION(4,10,0)
+#define IPIPE_X86_FPU_EAGER
+#endif
+
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,2,0)
 #include 
 #include 
diff --git a/kernel/cobalt/arch/x86/thread.c b/kernel/cobalt/arch/x86/thread.c
index 7fb136300..18cf636e5 100644
--- a/kernel/cobalt/arch/x86/thread.c
+++ b/kernel/cobalt/arch/x86/thread.c
@@ -28,9 +28,13 @@
 
 static struct kmem_cache *xstate_cache;
 
+#ifdef IPIPE_X86_FPU_EAGER
+#define fpu_kernel_xstate_size sizeof(struct fpu)
+#else
 #if LINUX_VERSION_CODE < KERNEL_VERSION(4,7,0)
 #define fpu_kernel_xstate_size xstate_size
 #endif
+#endif /* IPIPE_X86_FPU_EAGER */
 
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,6,0)
 #define cpu_has_xmm boot_cpu_has(X86_FEATURE_XMM)
@@ -199,14 +203,17 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
struct mm_struct *prev_mm, *next_mm;
 
prev = out_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
if (x86_fpregs_active(prev))
/*
 * __switch_to will try and use __unlazy_fpu, so we
 * need to clear the ts bit.
 */
clts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
next = in_tcb->core.host_task;
+#ifndef IPIPE_X86_FPU_EAGER
 #if LINUX_VERSION_CODE >= KERNEL_VERSION(4,2,0)
next->thread.fpu.counter = 0;
 #elif LINUX_VERSION_CODE >= KERNEL_VERSION(3,13,0)
@@ -214,6 +221,7 @@ void xnarch_switch_to(struct xnthread *out, struct xnthread 
*in)
 #else
next->fpu_counter = 0;
 #endif
+#endif /* ! IPIPE_X86_FPU_EAGER */
prev_mm = out_tcb->core.active_mm;
next_mm = in_tcb->core.mm;
if (next_mm == NULL) {
@@ -245,9 +253,13 @@ void xnarch_switch_to(struct xnthread *out, struct 
xnthread *in)
switch_to(prev, next, last);
 #endif /* LINUX_VERSION_CODE >= 4.8 */
 
+#ifndef IPIPE_X86_FPU_EAGER
stts();
+#endif /* ! IPIPE_X86_FPU_EAGER */
 }
 
+#ifndef IPIPE_X86_FPU_EAGER
+
 #ifdef CONFIG_X86_64
 #define XSAVE_PREFIX   "0x48,"
 #define XSAVE_SUFFIX   "q"
@@ -359,11 +371,21 @@ int xnarch_handle_fpu_fault(struct xnthread *from,
 
return 1;
 }
+#else /* IPIPE_X86_FPU_EAGER */
+
+int xnarch_handle_fpu_fault(struct xnthread *from,
+   struct xnthread *to, struct ipipe_trap_data *d)
+{
+   // in eager mode there are no such faults
+   BUG_ON(1);
+}
+#endif /* ! IPIPE_X86_FPU_EAGER */
 
 #define current_task_used_kfpu()

Re: [Xenomai] [PATCH 1/1] x86: make fpu switching eager

2018-09-14 Thread Henning Schild 
Am Mon, 27 Aug 2018 18:36:49 +0200
schrieb Jan Kiszka :

> On 2018-08-27 15:33, Henning Schild wrote:
> > Linux 4.14 dropped support for lazy fpu switching and in the 4.4
> > and 4.9 series similar changes where backported.
> > So we can assume that fpu switching is purely eager for those
> > Linux  
> 
> My reading of this patch is that we do not "assume" them to be eager,
> we enforce that for now - until the changes from the related stable
> merge do that.
> 
> > kernel versions. That simplifies things a lot and we can drop
> > several changes from the IPIPE patch.
> > On the Xenomai side the only thing we still have to care about is
> > the kernel fpu state when we interrupt an in kernel fpu user. But
> > we do that explicit and can drop the indirection active_(fp)state.
> >   
> 
> That patch resolving a mechanical merge conflict ahead of the merge, 
> right? Does it break the build?
> 
> > Signed-off-by: Henning Schild 
> > ---
> >   arch/x86/include/asm/fpu/internal.h | 30
> > -- arch/x86/include/asm/fpu/types.h
> > | 12  arch/x86/kernel/fpu/core.c  | 23
> > +-- arch/x86/kernel/fpu/init.c  |  5
> > + 4 files changed, 18 insertions(+), 52 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/fpu/internal.h
> > b/arch/x86/include/asm/fpu/internal.h index
> > 35ca184e83e1..6bdceba90f17 100644 ---
> > a/arch/x86/include/asm/fpu/internal.h +++
> > b/arch/x86/include/asm/fpu/internal.h @@ -13,7 +13,6 @@
> >   #include 
> >   #include 
> >   #include 
> > -#include 
> >   #include 
> >   
> >   #include 
> > @@ -190,24 +189,12 @@ static inline int copy_user_to_fregs(struct
> > fregs_state __user *fx) return user_insn(frstor %[fx], "=m" (*fx),
> > [fx] "m" (*fx)); }
> >   
> > -#ifdef CONFIG_IPIPE
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return fpu->active_state;
> > -}
> > -#else
> > -static inline union fpregs_state *active_fpstate(struct fpu *fpu)
> > -{
> > -   return >state;
> > -}
> > -#endif
> > -
> >   static inline void copy_fxregs_to_kernel(struct fpu *fpu)
> >   {
> > if (IS_ENABLED(CONFIG_X86_32))
> > -   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile( "fxsave %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else if (IS_ENABLED(CONFIG_AS_FXSAVEQ))
> > -   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (active_fpstate(fpu)->fxsave));
> > +   asm volatile("fxsaveq %[fx]" : [fx]
> > "=m" (fpu->state.fxsave)); else {
> > /* Using "rex64; fxsave %0" is broken because, if
> > the memory
> >  * operand uses any extended registers for
> > addressing, a second @@ -231,8 +218,8 @@ static inline void
> > copy_fxregs_to_kernel(struct fpu *fpu)
> >  * registers.
> >  */
> > asm volatile( "rex64/fxsave (%[fx])"
> > - : "=m" (active_fpstate(fpu)->fxsave)
> > - : [fx]
> > "R" (_fpstate(fpu)->fxsave));
> > + : "=m" (fpu->state.fxsave)
> > + : [fx] "R" (>state.fxsave));
> > }
> >   }
> >   
> > @@ -441,7 +428,7 @@ static inline int copy_user_to_xregs(struct
> > xregs_state __user *buf, u64 mask) static inline int
> > copy_fpregs_to_fpstate(struct fpu *fpu) {
> > if (likely(use_xsave())) {
> > -   copy_xregs_to_kernel(_fpstate(fpu)->xsave);
> > +   copy_xregs_to_kernel(>state.xsave);
> > return 1;
> > }
> >   
> > @@ -454,7 +441,7 @@ static inline int copy_fpregs_to_fpstate(struct
> > fpu *fpu)
> >  * Legacy FPU register saving, FNSAVE always clears FPU
> > registers,
> >  * so we have to mark them inactive:
> >  */
> > -   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (active_fpstate(fpu)->fsave));
> > +   asm volatile("fnsave %[fp]; fwait" : [fp]
> > "=m" (fpu->state.fsave)); 
> > return 0;
> >   }
> > @@ -609,8 +596,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> > fpu *new_fpu, int cpu)
> >  * If the task has used the math, pre-load the FPU on
> > xsave processors
> >  * or if the past 5 consecutive context-switches used
> > math. */
> > -   fpu.preload = !IS_ENABLED(CONFIG_IPIPE) &&
> > - static_cpu_has(X86_FEATURE_FPU) &&
> > +   fpu.preload = static_cpu_has(X86_FEATURE_FPU) &&
> >   new_fpu->fpstate_active &&
> >   (use_eager_fpu() || new_fpu->counter > 5);
> >   
> > @@ -660,7 +646,7 @@ switch_fpu_prepare(struct fpu *old_fpu, struct
> > fpu *new_fpu, int cpu) */
> >   static inline void switch_fpu_finish(struct fpu *new_fpu,
> > fpu_switch_t fpu_switch) {
> > -   if (!IS_ENABLED(CONFIG_IPIPE) && fpu_switch.preload)
> > +   if (fpu_switch.preload)
> > copy_kernel_to_fpregs(_fpu->state);
> >   }
> >   
> > diff --git a/arch/x86/include/asm/fpu/types.h
> > b/arch/x86/include/asm/fpu/types.h index

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Leopold Palomo-Avellaneda 
 idea. But this
>> change should be done by upstream. But if I'm not wrong, Phillipe said that 
>> it
>> hasn't an easy solution.
> 
> It has no easy solution if you want to do build a POSIX-only project purely 
> with linker arguments.
> When you can afford add some lines of (Xenomai-specific) code to your 
> project, it opens a lot possibilities.
> 
>>
>> But for the curious, I have done this example:
>>
>> https://github.com/iocroblab/xenomai-cmake
>>
>> but it's not polished and had some mistakes. The idea is to use any Xenomai
>> installation without touched and then use CMake to build your application.
> 
> Yes I get that, and I tried the same with FindXenomai. I consider the CMake 
> Config approach
> a lot better.

:-)

Cheers,

Leopold



-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: 
<http://xenomai.org/pipermail/xenomai/attachments/20180914/b038baff/attachment.sig>
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Leopold Palomo-Avellaneda 
On 14/09/18 09:45, Per Oberg wrote:

[...]

> 
> Being able to use the same code, without patches or a lot of defines 
> including other files is a very clean way of debugging your software. I often 
> set up Simulations where I use my laptop running or our controller, possibly 
> connected to remote hardware to debug stuff. For these cases  the POSIX skin 
> is very useful.
> 
>>> As noted by Henning, please look at 
>>> https://github.com/nolange/cmake_xenomai,
>>> could use some feedback =).
>>> Particularly look at the patchset which also removes some headaches with 
>>> linking
>>> precompiled object file for bootstrapping (but needs some upstream changes).
> 
>> Norbert, I have followed your emails and your project. You did a good
>> job, but I don't agree with your approach. My points are:
> 
>> - You are trying to convert Xenomai a CMake project and this probably
>> will not happen because Upstream is very happy with the autotools. I
>> don't like to touch anything from upstream. Maybe some patch, but
>> incorporated in Upstream.
> 
> What do you mean with "convert Xenomai a CMake project"? I feel that I am 
> missing something...
> Is it simply that  the "xeno-config" way of doing things isn't cmak-onic 
> enough for a "real" CMake project or is there something deeper?

well, I'm sorry I have been not clear. I'm saying the Norbert is trying to
generate the config files that normally are generating by cmake.

Leopold
-- 
--
Linux User 152692 GPG: 05F4A7A949A2D9AA
Catalonia
-
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

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

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Giulio Moro 
> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to 
> have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.

I normally disable wrappers and call explicitly the `__wrap_` equivalent when I 
want to use a Xenomai function , that is for instance `__wrap_pthread_create()` 
instead of `pthread_create()`.
I also add my own forward declaration, e.g.:

int __wrap_pthread_create(pthread_t *thread, const pthread_attr_t *attr, void 
*(*start_routine) (void *), void *arg);

But maybe this is already provided in some of the Cobalt headers.
___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Lange Norbert 
> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to 
> have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.

You can explicitly use the cobalt or std function with macros.
That said I have my issues with cascading headers from linux, c library and 
cobalt,
this is hard to follow with symbols potentially coming from anywhere.

> Norbert, I have followed your emails and your project. You did a good job,
> but I don't agree with your approach. My points are:
>
> - You are trying to convert Xenomai a CMake project and this probably will
> not happen because Upstream is very happy with the autotools. I don't like
> to touch anything from upstream. Maybe some patch, but incorporated in
> Upstream.

Sorry, that's nonsense, never thought about building Xenomai with CMake.

> - I would prefer follow the Upstream guidelines that recommends use xeno-
> config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.

I tried multiple approaches, using xeno-config fell out shortly.
-   it's (logically) an target "executable".
That imposes problems with CMake's normal search for those,
not to mention CI when your builder works in a partition with noexec.
I would want to use config-files directly or with a host-executable,
like pkg-config uses .pc files.
-   has problems if you relocate your build environment
I would prefer relative paths for simplicity
-   I need to extract all information and not just flags for ONE configuration
That’s the most important issue, I need the "building blocks" of the command
line, not ONE commandline. This means you need to know xeno-config
and its flags precisely and figure out how to dissect multiple outputs
in those "building blocks".
Fragile and not forwards-compatible.

Whats left is two variants:

FindXenomai - this would be placed in your project or up streamed in CMake.
Uses CMake functions to guess the paths, this might be hard to do with some 
libdir / includedir
Configurations and would need to be updated independently of Xenomai.

CMake Config files - you place those in /cmake/xenomai.
Those can be generated by config/install_cmakeconfig.sh from the repo (use same 
arguments as when configuring CMake).
The previously mentioned patchset adds those files to Xenomai and does this 
automatically when installing (using the autotools system).
Upstreaming in Xenomai would make everything hassle-free and 
forwards-compatible (the config files would always match the version).

The downside is of course that this would then be a burden to the Xenomai devs, 
but it should not need any changes outside of structural changes.
At which point someone will have to adapt CMake integration, however its done - 
I would prefer it to be done just once


The repo contains other changes, attempting to sanitize the bootstrapping 
methods,
Without those the provided examples might not work (only the upstream 
bootstrapping method will work).
I hope atleast those can be upstreamed.

> - I agree with Norbert that bootstraped code is not a good idea. But this
> change should be done by upstream. But if I'm not wrong, Phillipe said that it
> hasn't an easy solution.

It has no easy solution if you want to do build a POSIX-only project purely 
with linker arguments.
When you can afford add some lines of (Xenomai-specific) code to your project, 
it opens a lot possibilities.

>
> But for the curious, I have done this example:
>
> https://github.com/iocroblab/xenomai-cmake
>
> but it's not polished and had some mistakes. The idea is to use any Xenomai
> installation without touched and then use CMake to build your application.

Yes I get that, and I tried the same with FindXenomai. I consider the CMake 
Config approach
a lot better.

Norbert


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Julien Blanc 
Le vendredi 14 septembre 2018 à 02:45 -0500, Per Oberg a écrit :
> 
> This! 
> 
> Being able to use the same code, without patches or a lot of defines
> including other files is a very clean way of debugging your software.
> I often set up Simulations where I use my laptop running or our
> controller, possibly connected to remote hardware to debug stuff. For
> these cases  the POSIX skin is very useful.

I thought that was the purpose of the mercury core.

For a full xenomai application, the wrapping mechanism is nice. For a
mixed rt / non-rt executable, this tends to be full of pitfalls. The
__RT and __STD macros are of a great help in this regard. 

I also still wonder if there’s a way to make std::thread work in such a
mixed environment.

> What do you mean with "convert Xenomai a CMake project"? I feel that
> I am missing something...

I think it means "build xenomai with cmake" (which is unlikely to
happen afaik).

Regards,

Julien

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

Re: [Xenomai] Order options to build a Xenomai program

2018-09-14 Thread Per Oberg 

- Den 13 sep 2018, på kl 23:36, Leopold Palomo-Avellaneda l...@alaxarxa.net 
skrev:

> Hi,

> El 13/09/18 a les 14:42, Lange Norbert ha escrit:

>> link order is important and goes left-to-right, this seems to include
> > "wrappers",
>> which only wrap symbols that where already encountered (to the left of the
> > wrapper argument)

> [...]

>> The call to malloc is wrapped to __wrap_malloc and __real_malloc is wrapped 
>> to
> > malloc,
> > since there is no object file yet, this does nothing.
>> libmodechk exports __wrap_malloc and __real_malloc, yet no one cares and
> > --as-needed
> > will remove it as dependency
> > The app objects depend on malloc.

> > I am not sure where your dependency to __real_malloc comes from, but I 
> > suppose
>> It's from the bootstrap code, which would be needed to be linked before the
> > wrapper.
> > Probably weak dependencies further complicate things.

> I think that you got the point!!

> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer
> to have a RT API that links against RT libraries and you can mix the
> POSIX functions that you want in a clear way.

> OTOH I have to admit that convert a POSIX program to RT in an easy way
> is amazing.


This! 

Being able to use the same code, without patches or a lot of defines including 
other files is a very clean way of debugging your software. I often set up 
Simulations where I use my laptop running or our controller, possibly connected 
to remote hardware to debug stuff. For these cases  the POSIX skin is very 
useful.

> > As noted by Henning, please look at 
> > https://github.com/nolange/cmake_xenomai,
> > could use some feedback =).
> > Particularly look at the patchset which also removes some headaches with 
> > linking
> > precompiled object file for bootstrapping (but needs some upstream changes).

> Norbert, I have followed your emails and your project. You did a good
> job, but I don't agree with your approach. My points are:

> - You are trying to convert Xenomai a CMake project and this probably
> will not happen because Upstream is very happy with the autotools. I
> don't like to touch anything from upstream. Maybe some patch, but
> incorporated in Upstream.

What do you mean with "convert Xenomai a CMake project"? I feel that I am 
missing something...

Is it simply that  the "xeno-config" way of doing things isn't cmak-onic enough 
for a "real" CMake project or is there something deeper?

> - I would prefer follow the Upstream guidelines that recommends use
> xeno-config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.

> - I agree with Norbert that bootstraped code is not a good idea. But
> this change should be done by upstream. But if I'm not wrong, Phillipe
> said that it hasn't an easy solution.

> But for the curious, I have done this example:

> https://github.com/iocroblab/xenomai-cmake

> but it's not polished and had some mistakes. The idea is to use any
> Xenomai installation without touched and then use CMake to build your
> application.

> Cheers,

> Leopold

> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> -
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

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

Thanks,
Per Öberg 

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