[Xenomai-core] 2.6.16-rc6 support

[Xenomai-core] 2.6.16-rc6 support

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Hi,

Jeroen reported success much earlier, now I had to rebase my box on
upcoming 2.6.16. So I would like to post the result, maybe others are
interested in starting an early test as well. Attached is a cleanly
applying Ipipe patch for -rc6 and a fix for a name collision in
posix/syscall.c (there are other mutex functions in the kernel now...).

I'm writing this mail on a 2.6.16-Xenomai box (x86) under load (POSIX
skin+cyclictest, ongoing kernel-built), and all works smoothly. Hmm, a
few minutes for 4 rejected hunks of the standard patch, some further for
the naming clash, and even the tracer applied out-of-the-box - that was
too easy. ;)

Jan


PS: Gilles, as a tiny cleanup, I would suggest converting all syscall
wrapper functions in posix/syscall.c into static ones. They are only
used in that file.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: mutex-2.6.16.patch --]
[-- Type: text/x-patch; name="mutex-2.6.16.patch", Size: 3096 bytes --]

Index: ksrc/skins/posix/syscall.c
===================================================================
--- ksrc/skins/posix/syscall.c	(Revision 754)
+++ ksrc/skins/posix/syscall.c	(Arbeitskopie)
@@ -803,7 +803,7 @@
     return -EINTR;
 }
 
-int __mutex_init (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_init (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -831,7 +831,7 @@
     return 0;
 }
 
-int __mutex_destroy (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_destroy (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -856,7 +856,7 @@
     return -err;
 }
 
-int __mutex_lock (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_lock (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -874,7 +874,7 @@
     return -pse51_mutex_timedlock_break(&mx.shadow_mutex, XN_INFINITE);
 }
 
-int __mutex_timedlock (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_timedlock (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -901,7 +901,7 @@
     return -pse51_mutex_timedlock_break(&mx.shadow_mutex,ts2ticks_ceil(&ts)+1);
 }
 
-int __mutex_trylock (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_trylock (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -919,7 +919,7 @@
     return -pthread_mutex_trylock(&mx.native_mutex);
 }
 
-int __mutex_unlock (struct task_struct *curr, struct pt_regs *regs)
+int __pthread_mutex_unlock (struct task_struct *curr, struct pt_regs *regs)
 
 {
     union __xeno_mutex mx, *umx;
@@ -2070,12 +2070,12 @@
     [__pse51_clock_gettime] = { &__clock_gettime, __xn_exec_any },
     [__pse51_clock_settime] = { &__clock_settime, __xn_exec_any },
     [__pse51_clock_nanosleep] = { &__clock_nanosleep, __xn_exec_primary },
-    [__pse51_mutex_init] = { &__mutex_init, __xn_exec_any },
-    [__pse51_mutex_destroy] = { &__mutex_destroy, __xn_exec_any },
-    [__pse51_mutex_lock] = { &__mutex_lock, __xn_exec_primary },
-    [__pse51_mutex_timedlock] = { &__mutex_timedlock, __xn_exec_primary },
-    [__pse51_mutex_trylock] = { &__mutex_trylock, __xn_exec_primary },
-    [__pse51_mutex_unlock] = { &__mutex_unlock, __xn_exec_primary },
+    [__pse51_mutex_init] = { &__pthread_mutex_init, __xn_exec_any },
+    [__pse51_mutex_destroy] = { &__pthread_mutex_destroy, __xn_exec_any },
+    [__pse51_mutex_lock] = { &__pthread_mutex_lock, __xn_exec_primary },
+    [__pse51_mutex_timedlock] = { &__pthread_mutex_timedlock, __xn_exec_primary },
+    [__pse51_mutex_trylock] = { &__pthread_mutex_trylock, __xn_exec_primary },
+    [__pse51_mutex_unlock] = { &__pthread_mutex_unlock, __xn_exec_primary },
     [__pse51_cond_init] = { &__cond_init, __xn_exec_any },
     [__pse51_cond_destroy] = { &__cond_destroy, __xn_exec_any },
     [__pse51_cond_wait] = { &__cond_wait, __xn_exec_primary },

[-- Attachment #3: adeos-ipipe-2.6.16-rc6-i386-1.2-01.patch.bz2 --]
[-- Type: application/x-bzip2, Size: 32894 bytes --]

Re: [Xenomai-core] 2.6.16-rc6 support

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

Jan Kiszka wrote:
> Hi,
> 
> Jeroen reported success much earlier, now I had to rebase my box on
> upcoming 2.6.16. So I would like to post the result, maybe others are
> interested in starting an early test as well. Attached is a cleanly
> applying Ipipe patch for -rc6 and a fix for a name collision in
> posix/syscall.c (there are other mutex functions in the kernel now...).
> 

Uups, someone must have whispered to me that 2.6.16 will come out very
soon, and now it happened. The final patch seems to cause no problems to
the ipipe patch as well.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

[Xenomai-core] Re: 2.6.16-rc6 support

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > and a fix for a name collision in
 > posix/syscall.c (there are other mutex functions in the kernel now...).

Applied, thanks.

 > PS: Gilles, as a tiny cleanup, I would suggest converting all syscall
 > wrapper functions in posix/syscall.c into static ones. They are only
 > used in that file.

Done.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] 2.6.16-rc6 support

[Philippe Gerum]

Jan Kiszka wrote:
> Jan Kiszka wrote:
> 
>>Hi,
>>
>>Jeroen reported success much earlier, now I had to rebase my box on
>>upcoming 2.6.16. So I would like to post the result, maybe others are
>>interested in starting an early test as well. Attached is a cleanly
>>applying Ipipe patch for -rc6 and a fix for a name collision in
>>posix/syscall.c (there are other mutex functions in the kernel now...).
>>
> 
> 
> Uups, someone must have whispered to me that 2.6.16 will come out very
> soon, and now it happened. The final patch seems to cause no problems to
> the ipipe patch as well.
> 

Looks ok here too. I will upgrade the Adeos x86 support on this base. 
Thanks.

> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.