[Xenomai-git] Jan Kiszka : switchtest: Bail out early from rtswitch_ktask on termination

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: f09ad577f233ea03558053643fd260ffcfc0aaee
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=f09ad577f233ea03558053643fd260ffcfc0aaee

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Mon Nov 18 19:08:11 2013 +0100

switchtest: Bail out early from rtswitch_ktask on termination

rtswitch_pend_rt may have been interrupted if the task is supposed to
stop. Reorder the test for this in order to avoid starting to run on
invalid data.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 kernel/drivers/testing/switchtest.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/kernel/drivers/testing/switchtest.c 
b/kernel/drivers/testing/switchtest.c
index 6f77ee9..8850962 100644
--- a/kernel/drivers/testing/switchtest.c
+++ b/kernel/drivers/testing/switchtest.c
@@ -400,7 +400,7 @@ static void rtswitch_ktask(void *cookie)
 
rtswitch_pend_rt(ctx, task-base.index);
 
-   for(;;) {
+   while (!rtdm_task_should_stop()) {
if (task-base.flags  RTTST_SWTEST_USE_FPU)
fp_regs_set(fp_features, task-base.index + i * 1000);
 
@@ -433,9 +433,6 @@ static void rtswitch_ktask(void *cookie)
}
}
 
-   if (rtdm_task_should_stop())
-   break;
-
if (++i == 400)
i = 0;
}


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Jan Kiszka : cobalt: Add missing prefix to sc_cobalt_check_init

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: d4bb40ebb30595f9ec59b09db46388ed8f72ae8b
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=d4bb40ebb30595f9ec59b09db46388ed8f72ae8b

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Mon Nov 11 18:33:01 2013 +0100

cobalt: Add missing prefix to sc_cobalt_check_init

Pure cosmetic, no functional change.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 include/cobalt/uapi/syscall.h |2 +-
 kernel/cobalt/posix/syscall.c |2 +-
 lib/cobalt/mutex.c|2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/cobalt/uapi/syscall.h b/include/cobalt/uapi/syscall.h
index ed60c35..6fec38e 100644
--- a/include/cobalt/uapi/syscall.h
+++ b/include/cobalt/uapi/syscall.h
@@ -40,7 +40,7 @@
 #define sc_cobalt_clock_settime 16
 #define sc_cobalt_clock_nanosleep   17
 #define sc_cobalt_mutex_init18
-#define sc_cobalt_check_init19
+#define sc_cobalt_mutex_check_init  19
 #define sc_cobalt_mutex_destroy 20
 #define sc_cobalt_mutex_lock21
 #define sc_cobalt_mutex_timedlock   22
diff --git a/kernel/cobalt/posix/syscall.c b/kernel/cobalt/posix/syscall.c
index e3a135d..a4632d3 100644
--- a/kernel/cobalt/posix/syscall.c
+++ b/kernel/cobalt/posix/syscall.c
@@ -111,7 +111,7 @@ static struct xnsyscall cobalt_syscalls[] = {
SKINCALL_DEF(sc_cobalt_clock_settime, cobalt_clock_settime, any),
SKINCALL_DEF(sc_cobalt_clock_nanosleep, cobalt_clock_nanosleep, 
nonrestartable),
SKINCALL_DEF(sc_cobalt_mutex_init, cobalt_mutex_init, any),
-   SKINCALL_DEF(sc_cobalt_check_init, cobalt_mutex_check_init, any),
+   SKINCALL_DEF(sc_cobalt_mutex_check_init, cobalt_mutex_check_init, any),
SKINCALL_DEF(sc_cobalt_mutex_destroy, cobalt_mutex_destroy, any),
SKINCALL_DEF(sc_cobalt_mutex_lock, cobalt_mutex_lock, primary),
SKINCALL_DEF(sc_cobalt_mutex_timedlock, cobalt_mutex_timedlock, 
primary),
diff --git a/lib/cobalt/mutex.c b/lib/cobalt/mutex.c
index 9655eca..39d85a4 100644
--- a/lib/cobalt/mutex.c
+++ b/lib/cobalt/mutex.c
@@ -83,7 +83,7 @@ COBALT_IMPL(int, pthread_mutex_init, (pthread_mutex_t *mutex,
 
if (_mutex-magic == COBALT_MUTEX_MAGIC) {
err = -XENOMAI_SKINCALL1(__cobalt_muxid,
-sc_cobalt_check_init,_mutex);
+sc_cobalt_mutex_check_init,_mutex);
 
if (err)
return err;


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Jan Kiszka : cobalt/kernel: Provide uninterruptible xnthread_join for RTDM use cases

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: 7f28f772c97b72b5a6c6c6051aa8009bfd7fa4a8
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=7f28f772c97b72b5a6c6c6051aa8009bfd7fa4a8

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Wed Nov 20 19:49:38 2013 +0100

cobalt/kernel: Provide uninterruptible xnthread_join for RTDM use cases

The semantics of rtdm_task_destroy and rtdm_task_join mandate that the
specified task is truly history by the time these functions return. And
that has to include the case that the caller has a Linux signal pending.
Thus, we need a variant of xnthread_join that waits unconditionally for
thread termination.

This fixes rare crashes when terminating switchtest early.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 include/cobalt/kernel/thread.h |2 +-
 include/rtdm/rtdm_driver.h |2 +-
 kernel/cobalt/posix/thread.c   |2 +-
 kernel/cobalt/rtdm/drvlib.c|2 +-
 kernel/cobalt/thread.c |7 +--
 5 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/include/cobalt/kernel/thread.h b/include/cobalt/kernel/thread.h
index aa2fd46..6328049 100644
--- a/include/cobalt/kernel/thread.h
+++ b/include/cobalt/kernel/thread.h
@@ -417,7 +417,7 @@ int xnthread_set_slice(struct xnthread *thread,
 
 void xnthread_cancel(struct xnthread *thread);
 
-int xnthread_join(struct xnthread *thread);
+int xnthread_join(struct xnthread *thread, bool uninterruptible);
 
 #ifdef CONFIG_SMP
 int xnthread_migrate(int cpu);
diff --git a/include/rtdm/rtdm_driver.h b/include/rtdm/rtdm_driver.h
index 3c8c270..71a03ab 100644
--- a/include/rtdm/rtdm_driver.h
+++ b/include/rtdm/rtdm_driver.h
@@ -1094,7 +1094,7 @@ void rtdm_task_busy_sleep(nanosecs_rel_t delay);
 static inline void rtdm_task_destroy(rtdm_task_t *task)
 {
xnthread_cancel(task);
-   xnthread_join(task);
+   xnthread_join(task, true);
 }
 
 static inline int rtdm_task_should_stop(void)
diff --git a/kernel/cobalt/posix/thread.c b/kernel/cobalt/posix/thread.c
index 7ba91fc..75fc1f1 100644
--- a/kernel/cobalt/posix/thread.c
+++ b/kernel/cobalt/posix/thread.c
@@ -1108,7 +1108,7 @@ int cobalt_thread_join(unsigned long pth)
if (thread == NULL)
return -ESRCH;
 
-   return xnthread_join(thread-threadbase);
+   return xnthread_join(thread-threadbase, false);
 }
 
 int cobalt_thread_stat(pid_t pid,
diff --git a/kernel/cobalt/rtdm/drvlib.c b/kernel/cobalt/rtdm/drvlib.c
index 30ea6a3..bd35f9a 100644
--- a/kernel/cobalt/rtdm/drvlib.c
+++ b/kernel/cobalt/rtdm/drvlib.c
@@ -445,7 +445,7 @@ void rtdm_task_join_nrt(rtdm_task_t *task, unsigned int 
poll_delay)
trace_mark(xn_rtdm, task_joinnrt, thread %p poll_delay %u,
   task, poll_delay);
 
-   xnthread_join(task);
+   xnthread_join(task, true);
 }
 
 EXPORT_SYMBOL_GPL(rtdm_task_join_nrt);
diff --git a/kernel/cobalt/thread.c b/kernel/cobalt/thread.c
index a6cb852..76a2443 100644
--- a/kernel/cobalt/thread.c
+++ b/kernel/cobalt/thread.c
@@ -1583,7 +1583,7 @@ EXPORT_SYMBOL_GPL(xnthread_cancel);
  * Rescheduling: always if @a thread did not terminate yet at the time
  * of the call.
  */
-int xnthread_join(struct xnthread *thread)
+int xnthread_join(struct xnthread *thread, bool uninterruptible)
 {
unsigned int tag;
spl_t s;
@@ -1616,7 +1616,10 @@ int xnthread_join(struct xnthread *thread)
 * wait queue is quite unlikely. In any case, we run in
 * secondary mode.
 */
-   if (wait_event_interruptible(nkjoinq, thread-idtag != tag)) {
+   if (uninterruptible)
+   wait_event(nkjoinq, thread-idtag != tag);
+   else if (wait_event_interruptible(nkjoinq,
+ thread-idtag != tag)) {
xnlock_get_irqsave(nklock, s);
if (thread-idtag == tag)
xnthread_clear_state(thread, XNJOINED);


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Jan Kiszka : xeno-test: Use new -E switch of clocktest

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: 40163e96b7534127ec7b77267d03ee07080ad406
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=40163e96b7534127ec7b77267d03ee07080ad406

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Fri Nov  8 19:24:37 2013 +0100

xeno-test: Use new -E switch of clocktest

Just to make sure it's used in our own testsuite.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 testsuite/xeno-test/xeno-test.in |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuite/xeno-test/xeno-test.in b/testsuite/xeno-test/xeno-test.in
index ea3c042..9b00b55 100644
--- a/testsuite/xeno-test/xeno-test.in
+++ b/testsuite/xeno-test/xeno-test.in
@@ -45,7 +45,7 @@ echo 0  /proc/xenomai/latency || :
 testdir=@testdir@
 
 $testdir/arith
-$testdir/clocktest -D -T 30 -C 65578 || $testdir/clocktest -T 30
+$testdir/clocktest -D -T 30 -E -C 42 || $testdir/clocktest -T 30
 $testdir/switchtest -T 30
 $testdir/cond-torture
 # $testdir/mutex-torture


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Jan Kiszka : switchtest: Avoid clashes RTSWITCH_* vs. RTTST_SWTEST_* constants

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: d144f02ed458e941aa603480b43c1df7c1372bb5
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=d144f02ed458e941aa603480b43c1df7c1372bb5

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Wed Nov 20 19:53:12 2013 +0100

switchtest: Avoid clashes RTSWITCH_* vs. RTTST_SWTEST_* constants

Namely RTTST_SWTEST_FREEZE and RTSWITCH_RT were using the same value.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 kernel/drivers/testing/switchtest.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/drivers/testing/switchtest.c 
b/kernel/drivers/testing/switchtest.c
index 8850962..836194b 100644
--- a/kernel/drivers/testing/switchtest.c
+++ b/kernel/drivers/testing/switchtest.c
@@ -8,9 +8,9 @@
 #include rtdm/rtdm_driver.h
 #include asm/xenomai/fptest.h
 
-#define RTSWITCH_RT  0x4
+#define RTSWITCH_RT  0x1
 #define RTSWITCH_NRT 0
-#define RTSWITCH_KERNEL  0x8
+#define RTSWITCH_KERNEL  0x2
 
 typedef struct {
struct rttst_swtest_task base;


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Gernot Hillier : Silence unused_result warning from write()

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: 0ddf06f1d6f7b328bbe456d8967a0ad672585a39
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=0ddf06f1d6f7b328bbe456d8967a0ad672585a39

Author: Gernot Hillier gernot.hill...@siemens.com
Date:   Mon Nov 11 11:23:29 2013 +0100

Silence unused_result warning from write()

Some glibc versions mark write() with attribute warn_unused_result (found in
Ubuntu 12.04 / eglibc 2.15 / gcc 4.6.3), so we need to silence this warning,
especially because we're building with -Werror.

Signed-off-by: Gernot Hillier gernot.hill...@siemens.com
Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 lib/cobalt/init.c   |3 ++-
 testsuite/latency/latency.c |2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/cobalt/init.c b/lib/cobalt/init.c
index bc32a50..8328c7f 100644
--- a/lib/cobalt/init.c
+++ b/lib/cobalt/init.c
@@ -54,7 +54,8 @@ int __rtdm_fd_start = INT_MAX;
 static void sigill_handler(int sig)
 {
const char m[] = no Xenomai support in kernel?\n;
-   write(2, m, sizeof(m) - 1);
+   ssize_t rc __attribute__ ((unused));
+   rc = write(2, m, sizeof(m) - 1);
exit(EXIT_FAILURE);
 }
 
diff --git a/testsuite/latency/latency.c b/testsuite/latency/latency.c
index 7c5099b..32e59b5 100644
--- a/testsuite/latency/latency.c
+++ b/testsuite/latency/latency.c
@@ -507,7 +507,7 @@ static void sigdebug(int sig, siginfo_t *si, void *context)
case SIGDEBUG_WATCHDOG:
n = snprintf(buffer, sizeof(buffer), %s\n,
 reason_str[reason]);
-   write(STDERR_FILENO, buffer, n);
+   n = write(STDERR_FILENO, buffer, n);
exit(EXIT_FAILURE);
}
 


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

[Xenomai-git] Jan Kiszka : clocktest: Update to new clocks and clock encoding scheme

2013-12-17 Thread git repository hosting 
Module: xenomai-jki
Branch: for-forge
Commit: 9fc1ce1503044c62f6f153c8a05bc592eb21dd5a
URL:
http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=9fc1ce1503044c62f6f153c8a05bc592eb21dd5a

Author: Jan Kiszka jan.kis...@siemens.com
Date:   Fri Nov  8 19:04:11 2013 +0100

clocktest: Update to new clocks and clock encoding scheme

Add -E command line option to specify an extension clock more
conveniently. CLOCK_HOST_REALTIME is not selected by -E -C 42. Also
add decoding of CLOCK_MONOTONIC_RAW.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com

---

 testsuite/clocktest/clocktest.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/testsuite/clocktest/clocktest.c b/testsuite/clocktest/clocktest.c
index 3a34998..cea8de3 100644
--- a/testsuite/clocktest/clocktest.c
+++ b/testsuite/clocktest/clocktest.c
@@ -246,13 +246,18 @@ int main(int argc, char *argv[])
int i;
int c;
int d = 0;
+   int ext = 0;
 
-   while ((c = getopt(argc, argv, C:T:D)) != EOF)
+   while ((c = getopt(argc, argv, C:ET:D)) != EOF)
switch (c) {
case 'C':
clock_id = atoi(optarg);
break;
 
+   case 'E':
+   ext = 1;
+   break;
+
case 'T':
alarm(atoi(optarg));
break;
@@ -264,6 +269,7 @@ int main(int argc, char *argv[])
default:
fprintf(stderr, usage: clocktest [options]\n
  [-C clock_id]  # tested clock, 
default=%d (CLOCK_REALTIME)\n
+ [-E] # -C specifies 
extension clock\n
  [-T test_duration_seconds] # default=0, so 
^C to end\n
  [-D] # print extra 
diagnostics for CLOCK_HOST_REALTIME\n,
CLOCK_REALTIME);
@@ -276,6 +282,8 @@ int main(int argc, char *argv[])
 
init_lock(lock);
 
+   if (ext)
+   clock_id = __COBALT_CLOCK_CODE(clock_id);
if (d  clock_id == CLOCK_HOST_REALTIME)
show_hostrt_diagnostics();
 
@@ -292,7 +300,8 @@ int main(int argc, char *argv[])
   (void *)(long)i);
}
 
-   printf(== Tested clock: %d (, clock_id);
+   printf(== Tested %sclock: %d (, ext ? extension  : ,
+  __COBALT_CLOCK_INDEX(clock_id));
switch (clock_id) {
case CLOCK_REALTIME:
printf(CLOCK_REALTIME);
@@ -302,6 +311,10 @@ int main(int argc, char *argv[])
printf(CLOCK_MONOTONIC);
break;
 
+   case CLOCK_MONOTONIC_RAW:
+   printf(CLOCK_MONOTONIC_RAW);
+   break;
+
case CLOCK_HOST_REALTIME:
printf(CLOCK_HOST_REALTIME);
break;


___
Xenomai-git mailing list
Xenomai-git@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai-git

Re: [Xenomai] forge: Trying to understand new semaphore code

2013-12-17 Thread Philippe Gerum 

On 12/16/2013 11:27 PM, Gilles Chanteperdrix wrote:


Hi,

here comes the fix for the two issues. If we are allowed to rebase
the next branch, I suggest to fold it with the original semaphore
commit. Otherwise, I can push this commit on my branch.


Rebasing is always allowed on -next, I'll pick this up. Thanks.



diff --git a/kernel/cobalt/posix/nsem.c b/kernel/cobalt/posix/nsem.c
index 7e66ea8..72edacb 100644
--- a/kernel/cobalt/posix/nsem.c
+++ b/kernel/cobalt/posix/nsem.c
@@ -119,9 +119,10 @@ nsem_open(struct __shadow_sem __user *ushadow, const char 
*name,
if ((oflags  O_CREAT) == 0)
return ERR_PTR(-ENOENT);

-   rc = cobalt_sem_init_inner
+   sem = cobalt_sem_init_inner
(name[1], shadow, SEM_PSHARED, value);
-   if (rc  0) {
+   if (IS_ERR(sem)) {
+   rc = PTR_ERR(sem);
if (rc == -EEXIST)
goto retry_bind;
return ERR_PTR(rc);
@@ -132,8 +133,6 @@ nsem_open(struct __shadow_sem __user *ushadow, const char 
*name,
return ERR_PTR(-EFAULT);
}
handle = shadow.handle;
-   sem = xnregistry_fetch(handle);
-   ++sem-refs;
}

u = xnmalloc(sizeof(*u));
@@ -154,9 +153,6 @@ nsem_open(struct __shadow_sem __user *ushadow, const char 
*name,
--sem-refs;
xnlock_put_irqrestore(nklock, s);

-   if (rc == -EWOULDBLOCK)
-   cobalt_sem_destroy_inner(sem-handle);
-
xnfree(u);
u = v;
} else {
diff --git a/kernel/cobalt/posix/sem.c b/kernel/cobalt/posix/sem.c
index 2f632f6..93fb6d8 100644
--- a/kernel/cobalt/posix/sem.c
+++ b/kernel/cobalt/posix/sem.c
@@ -32,6 +32,7 @@
   *@{*/

  #include stddef.h
+#include linux/err.h
  #include internal.h
  #include thread.h
  #include clock.h
@@ -82,8 +83,9 @@ int cobalt_sem_destroy_inner(xnhandle_t handle)
return ret;
  }

-int cobalt_sem_init_inner(const char *name, struct __shadow_sem *sm,
-   int flags, unsigned int value)
+struct cobalt_sem *
+cobalt_sem_init_inner(const char *name, struct __shadow_sem *sm,
+   int flags, unsigned int value)
  {
struct list_head *semq;
struct cobalt_sem *sem, *osem;
@@ -94,11 +96,11 @@ int cobalt_sem_init_inner(const char *name, struct 
__shadow_sem *sm,
spl_t s;

if ((flags  SEM_PULSE) != 0  value  0)
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);

sem = xnmalloc(sizeof(*sem));
if (sem == NULL)
-   return -ENOSPC;
+   return ERR_PTR(-ENOSPC);

snprintf(sem-name, sizeof(sem-name), %s, name);

@@ -159,7 +161,7 @@ int cobalt_sem_init_inner(const char *name, struct 
__shadow_sem *sm,
datp-flags = flags;
sem-flags = flags;
sem-owningq = kq;
-   sem-refs = 1;
+   sem-refs = name[0] ? 2 : 1;

sm-magic = name[0] ? COBALT_NAMED_SEM_MAGIC : COBALT_SEM_MAGIC;
sm-handle = sem-handle;
@@ -168,7 +170,7 @@ int cobalt_sem_init_inner(const char *name, struct 
__shadow_sem *sm,
sm-datp_offset = -sm-datp_offset;
xnlock_put_irqrestore(nklock, s);

-   return 0;
+   return sem;

err_lock_put:
xnlock_put_irqrestore(nklock, s);
@@ -176,7 +178,7 @@ int cobalt_sem_init_inner(const char *name, struct 
__shadow_sem *sm,
err_free_sem:
xnfree(sem);

-   return ret;
+   return ERR_PTR(ret);
  }

  /**
@@ -653,14 +655,15 @@ static int sem_getvalue(xnhandle_t handle, int *value)
  int cobalt_sem_init(struct __shadow_sem __user *u_sem, int pshared, unsigned 
value)
  {
struct __shadow_sem sm;
+   struct cobalt_sem *sem;
int err;

if (__xn_safe_copy_from_user(sm, u_sem, sizeof(sm)))
return -EFAULT;

-   err = cobalt_sem_init_inner(, sm, pshared ? SEM_PSHARED : 0, value);
-   if (err  0)
-   return err;
+   sem = cobalt_sem_init_inner(, sm, pshared ? SEM_PSHARED : 0, value);
+   if (IS_ERR(sem))
+   return PTR_ERR(sem);

return __xn_safe_copy_to_user(u_sem, sm, sizeof(*u_sem));
  }
@@ -735,6 +738,7 @@ int cobalt_sem_init_np(struct __shadow_sem __user *u_sem,
   int flags, unsigned value)
  {
struct __shadow_sem sm;
+   struct cobalt_sem *sem;
int err;

if (__xn_safe_copy_from_user(sm, u_sem, sizeof(sm)))
@@ -744,9 +748,9 @@ int cobalt_sem_init_np(struct __shadow_sem __user *u_sem,
  SEM_WARNDEL|SEM_RAWCLOCK|SEM_NOBUSYDEL))
return -EINVAL;

-   err = cobalt_sem_init_inner(, sm, flags, value);
-   if (err  0)
-   return err;
+   sem = cobalt_sem_init_inner(, sm, flags, value);
+   if (IS_ERR(sem))
+

[Xenomai] debian xenomai package

2013-12-17 Thread Michael Haberler 
we're considering how to package LinuxCNC such that it can eventually be 
included in debian

the core package will support RT-PREEMPT because an RT-PREEMPT kernel is 
available stock in debian; the other RT kernels will be covered by separate 
packages (Xenomai, RTAI).

so far we've used the xenomai userland support straight off the git repo, but 
it might make sense to switch to 
http://packages.debian.org/jessie/xenomai-runtime for one less external raw 
repo dependency

question - is this a recommendable route?

(depends a bit on how well the debian package tracks the repo - does this 
happen 'occasionally', or per-release?; so far we havent had major issues with 
userland support but better ask before relying on something only loosely 
maintained)

thanks!

- Michael 
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] debian xenomai package

2013-12-17 Thread Gilles Chanteperdrix 

On 12/17/2013 12:19 PM, Michael Haberler wrote:

we're considering how to package LinuxCNC such that it can eventually
be included in debian

the core package will support RT-PREEMPT because an RT-PREEMPT kernel
is available stock in debian; the other RT kernels will be covered by
separate packages (Xenomai, RTAI).

so far we've used the xenomai userland support straight off the git
repo, but it might make sense to switch to
http://packages.debian.org/jessie/xenomai-runtime for one less
external raw repo dependency

question - is this a recommendable route?

(depends a bit on how well the debian package tracks the repo - does
this happen 'occasionally', or per-release?; so far we havent had
major issues with userland support but better ask before relying on
something only loosely maintained)


I think the user-space run-time is not really a problem, Xenomai 2.6 
does not need any particular option on configure command line to avoid 
issues, the defaults are fine for all architectures. Even the Debian 
project rule files, which passes options which either no longer even 
exists or are not useful, gets a working build.


What is much harder, and not really already available in the Debian 
project is to package a kernel compiled with the right options to avoid 
any issues, and avoid the hassle to all users to have to find out these 
options by themselves, whereas, at least on x86, we can provide one such 
Debian-like kernel. I did it for Linux 3.5.7 on xenomai 2.6.2.1, but did 
not renew the experience with xenomai 2.6.3 because nobody downloaded 
the .debs. But the reprepro directory is still there, so restarting it 
would be easy.


--
Gilles.

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

Re: [Xenomai] debian xenomai package

2013-12-17 Thread Leopold Palomo-Avellaneda 
A Dimarts, 17 de desembre de 2013, Gilles Chanteperdrix va escriure:
 On 12/17/2013 12:19 PM, Michael Haberler wrote:
  we're considering how to package LinuxCNC such that it can eventually
  be included in debian
 
  the core package will support RT-PREEMPT because an RT-PREEMPT kernel
  is available stock in debian; the other RT kernels will be covered by
  separate packages (Xenomai, RTAI).
 
  so far we've used the xenomai userland support straight off the git
  repo, but it might make sense to switch to
  http://packages.debian.org/jessie/xenomai-runtime for one less
  external raw repo dependency
 
  question - is this a recommendable route?
 
  (depends a bit on how well the debian package tracks the repo - does
  this happen 'occasionally', or per-release?; so far we havent had
  major issues with userland support but better ask before relying on
  something only loosely maintained)
 
 I think the user-space run-time is not really a problem, Xenomai 2.6 
 does not need any particular option on configure command line to avoid 
 issues, the defaults are fine for all architectures. Even the Debian 
 project rule files, which passes options which either no longer even 
 exists or are not useful, gets a working build.
 
 What is much harder, and not really already available in the Debian 
 project is to package a kernel compiled with the right options to avoid 
 any issues, and avoid the hassle to all users to have to find out these 
 options by themselves,

I like the  right options to avoid any issues. 

Really, it's possible to provide a Xenomai patched kernel for the 95% of the 
users/hardware? 

 whereas, at least on x86, we can provide one such 
 Debian-like kernel. I did it for Linux 3.5.7 on xenomai 2.6.2.1, but did 
 not renew the experience with xenomai 2.6.3 because nobody downloaded 
 the .debs. But the reprepro directory is still there, so restarting it 
 would be easy.

Well, I use my own package, but I have not any problem to promote this ones. 
We can talk. I have no interest in maintain any kernel package, on the 
contrary.

Leo



-- 
--
Linux User 152692
Catalonia
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 
http://www.xenomai.org/pipermail/xenomai/attachments/20131217/bd607f36/attachment.sig
___
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] debian xenomai package

2013-12-17 Thread Gilles Chanteperdrix 

On 12/17/2013 03:28 PM, Leopold Palomo-Avellaneda wrote:

A Dimarts, 17 de desembre de 2013, Gilles Chanteperdrix va escriure:

On 12/17/2013 12:19 PM, Michael Haberler wrote:

we're considering how to package LinuxCNC such that it can eventually
be included in debian

the core package will support RT-PREEMPT because an RT-PREEMPT kernel
is available stock in debian; the other RT kernels will be covered by
separate packages (Xenomai, RTAI).

so far we've used the xenomai userland support straight off the git
repo, but it might make sense to switch to
http://packages.debian.org/jessie/xenomai-runtime for one less
external raw repo dependency

question - is this a recommendable route?

(depends a bit on how well the debian package tracks the repo - does
this happen 'occasionally', or per-release?; so far we havent had
major issues with userland support but better ask before relying on
something only loosely maintained)


I think the user-space run-time is not really a problem, Xenomai 2.6
does not need any particular option on configure command line to avoid
issues, the defaults are fine for all architectures. Even the Debian
project rule files, which passes options which either no longer even
exists or are not useful, gets a working build.

What is much harder, and not really already available in the Debian
project is to package a kernel compiled with the right options to avoid
any issues, and avoid the hassle to all users to have to find out these
options by themselves,


I like the  right options to avoid any issues.

Really, it's possible to provide a Xenomai patched kernel for the 95% of the
users/hardware?


Yes. Starting with the I-pipe core patches, definitely. And if not, I 
think this is something we should work on. Because in the long run, if 
users installed pre-packaged kernels and did not have to follow the 
traditional trial-and-error process of configuring kernels for xenomai, 
we would have less questions on this subject on the mailing list.





whereas, at least on x86, we can provide one such
Debian-like kernel. I did it for Linux 3.5.7 on xenomai 2.6.2.1, but did
not renew the experience with xenomai 2.6.3 because nobody downloaded
the .debs. But the reprepro directory is still there, so restarting it
would be easy.


Well, I use my own package, but I have not any problem to promote this ones.
We can talk. I have no interest in maintain any kernel package, on the
contrary.


That is my point, the same work, configuring the kernel, is replicated 
by almost every user of xenomai, for almost no good reason. It makes 
sense to optimize compilation for one processor on the ARM architecture, 
because you easily loose microseconds latency with the wrong option. On 
x86 however, I do not think there is not much to gain (except 
compilation time) by trimming down the configuration.



--
Gilles.

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