date:20060317

Re: [Xenomai-core] VxWorks skin improvement

2006-03-17 Thread Niklaus Giger

Am Donnerstag, 16. März 2006 14:53 schrieb Philippe Gerum:
 I'm currently working on extending the VxWorks skin so that it is going to
 be callable from user-space directly, without needing the UVM environment.
 This will also make its functional extension easier in the future,
 especially with respect to bsp-related services.

 While I'm at it, I'd also like to polish a few corner cases, so that we
 have the closest possible emulation of the original RTOS services.
 Unfortunately, the VxWorks documentation is rather terse on some
 behavioural aspects, and I have no VxWorks target at hand to test and check
 them. Therefore, I definitely need help from people reading this list who
 also happen to be VxWorks users, for providing the following missing bits
 of information:

 - How does taskName() behave when passed a null task id? Is it equivalent
 to specifying taskIdSelf(), or does it lead to a NULL error return?
It behaves like taskName(taskIdSelf()). see vx_skin.c.
Output was
- vx_skin_test_1

myTaskName is 0xf40500 tShell
value = 31 = 0x1f

 - How does msgQSend() behave when passed an invalid message priority, i.e.
 neither MSG_PRI_NORMAL nor MSG_PRI_URGENT?
It doesn't care (see pMsgQue.cpp).
Output was
- test_init
task1 started
endTime   1834779057842028544
startTime 1832156649595338752
diff      2622408246689792 2622408246689 microSecs per run 26224082466
task1 nrQuestions 100 nrAnswers 100 nrSwitches 100
value = 0 = 0x0
 - How does taskInit() behave when passed an invalid set of task options?
 Are the invalid flags ignored, or does the routine return an error status?
All invalid bits arg ignored, no error returned. see vx_skin.c.
Output was:
- vx_skin_test_2

taskInit status is 0

taskOptionGet returns 0 is -1
value = 31 = 0x1f                 
 If you happen to have a VxWorks target at hand regardless of the
 architecture, and are willing to help improving the behavioural correctness
 of the VxWorks skin, then your input will be most welcome.
Hope this help. Please feel free to ask for more tests.
What about a vxWorks test suite? I would like to contribute to it. (At least 
as soon as I have a working Xenomai environment again.) And I would be much 
more confident to recommend Xenomai if it had test suites for its various 
skins. I hope to be able to make some contributions once I get approval to 
put a few of our internal test routines available under a free license.

Best regards

Niklaus Giger
/*
 * Copyright (C) 2005 Niklaus Giger [EMAIL PROTECTED].
 *
 * vxWorks is a registered trademark of Wind River Systems, Inc.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *
 * Hopefully this program lets you compare the relative performance of
 * taskSwitches and message passing between an original vxWorks image and
 * a xenomai based port.
 */

#ifdef XENOMAI
#include xeno_config.h
#include vxworks/vxworks.h
#include xenomai/timer.h
MODULE_LICENSE(GPL);
#else
#include vxWorks.h
#include stdio.h
#include msgQLib.h
#include taskLib.h
#include sysLib.h
#include arch/ppc/vxPpcLib.h
#define xnprintf printf
#define taskExit exit
#define RTIME UINT64
RTIME rt_timer_tsc();

RTIME rt_timer_tsc()
{
   UINT32 low, high;
   UINT64 res;
   vxTimeBaseGet (low, high);
   res = (UINT64) low + ((UINT64) high)32;
   return res;
}
#endif


#define TASK_PRI115
#define STACK_SIZE  8192

MSG_Q_ID question_qid, answer_qid;

int producer_tid,
   consumer_tid,
   test_tid;
static int nrQuestions;
static int nrAnswers;
static int nrSwitches;
void reportState(const char *where)
{
  xnprintf(%s nrQuestions %d nrAnswers %d nrSwitches %d\n,
   where, nrQuestions, nrAnswers, nrSwitches);
}

#define NR_RUNS 100
void task1 (int a0, int a1, int a2, int a3, int a4,
int a5, int a6, int a7, int a8, int a9)
{
int msg;
int sz;
int j;
RTIME diff, startTime, endTime;
xnprintf(task1 started\n);
startTime = rt_timer_tsc();
for (j=0; jNR_RUNS; j++)
{
	// taskDelay(sysClkRateGet()/2);
	// startTime = rt_timer_tsc();
  msg = nrQuestions;
  msgQSend(question_qid,
   (char *)msg,sizeof(msg),WAIT_FOREVER,MSG_PRI_NORMAL);
	  ++nrQuestions;
  if ( (sz = msgQReceive(answer_qid,
(char *)msg,sizeof(msg),WAIT_FOREVER)) == ERROR)
  {
reportState(__func__);

[Xenomai-core] [RFC][PATCH] security check for skin access

2006-03-17 Thread Jan Kiszka

Hi,

you all may know that Xenomai provides a bulk of very powerful
interfaces to userspace real-time applications. But not everyone may
have thought about the fact yet that these syscall extensions are
accessible for *all* users in the system!

Well, real-time and security is a more complex topic, but we should at
least restore the same level of security which Linux provides. For this
purpose, the attached (and long-planned) patch adds basic access control
to all Xenomai skin services by requiring CAP_SYS_NICE, i.e. the same
capability that is also required to manipulate the normal Linux
scheduling parameters.

I would suggest to merge it, either as an option (with default=y), or
unconditionally (it's just a tiny additional check in the syscall path).

Jan
Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c   (revision 719)
+++ ksrc/nucleus/shadow.c   (working copy)
@@ -1141,6 +1141,12 @@ static inline int do_hisyscall_event (un
 if (!__xn_reg_mux_p(regs))
goto linux_syscall;
 
+if (unlikely(!cap_raised(p-cap_effective, CAP_SYS_NICE)))
+   {
+   __xn_error_return(regs,-EPERM);
+   return RTHAL_EVENT_STOP;
+   }
+
 muxid = __xn_mux_id(regs);
 muxop = __xn_mux_op(regs);
 


signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [RFC][PATCH] security check for skin access

2006-03-17 Thread Philippe Gerum


Jan Kiszka wrote:

Hi,

you all may know that Xenomai provides a bulk of very powerful
interfaces to userspace real-time applications. But not everyone may
have thought about the fact yet that these syscall extensions are
accessible for *all* users in the system!

Well, real-time and security is a more complex topic, but we should at
least restore the same level of security which Linux provides. For this
purpose, the attached (and long-planned) patch adds basic access control
to all Xenomai skin services by requiring CAP_SYS_NICE, i.e. the same
capability that is also required to manipulate the normal Linux
scheduling parameters.

I would suggest to merge it, either as an option (with default=y), or
unconditionally (it's just a tiny additional check in the syscall path).


Applied, thanks.



Jan




Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c   (revision 719)
+++ ksrc/nucleus/shadow.c   (working copy)
@@ -1141,6 +1141,12 @@ static inline int do_hisyscall_event (un
 if (!__xn_reg_mux_p(regs))
goto linux_syscall;
 
+if (unlikely(!cap_raised(p-cap_effective, CAP_SYS_NICE)))

+   {
+   __xn_error_return(regs,-EPERM);
+   return RTHAL_EVENT_STOP;
+   }
+
 muxid = __xn_mux_id(regs);
 muxop = __xn_mux_op(regs);
 





___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core



--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] [RFC][PATCH] security check for skin access

2006-03-17 Thread Philippe Gerum


Jan Kiszka wrote:

Hi,

you all may know that Xenomai provides a bulk of very powerful
interfaces to userspace real-time applications. But not everyone may
have thought about the fact yet that these syscall extensions are
accessible for *all* users in the system!

Well, real-time and security is a more complex topic, but we should at
least restore the same level of security which Linux provides. For this
purpose, the attached (and long-planned) patch adds basic access control
to all Xenomai skin services by requiring CAP_SYS_NICE, i.e. the same
capability that is also required to manipulate the normal Linux
scheduling parameters.

I would suggest to merge it, either as an option (with default=y), or
unconditionally (it's just a tiny additional check in the syscall path).


Also added the CONFIG_OPT_SECURITY_ACCESS switch to make this check conditional.



Jan




Index: ksrc/nucleus/shadow.c
===
--- ksrc/nucleus/shadow.c   (revision 719)
+++ ksrc/nucleus/shadow.c   (working copy)
@@ -1141,6 +1141,12 @@ static inline int do_hisyscall_event (un
 if (!__xn_reg_mux_p(regs))
goto linux_syscall;
 
+if (unlikely(!cap_raised(p-cap_effective, CAP_SYS_NICE)))

+   {
+   __xn_error_return(regs,-EPERM);
+   return RTHAL_EVENT_STOP;
+   }
+
 muxid = __xn_mux_id(regs);
 muxop = __xn_mux_op(regs);
 





___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core



--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] VxWorks skin improvement

2006-03-17 Thread Philippe Gerum


Niklaus Giger wrote:

Am Donnerstag, 16. März 2006 14:53 schrieb Philippe Gerum:


I'm currently working on extending the VxWorks skin so that it is going to
be callable from user-space directly, without needing the UVM environment.
This will also make its functional extension easier in the future,
especially with respect to bsp-related services.

While I'm at it, I'd also like to polish a few corner cases, so that we
have the closest possible emulation of the original RTOS services.
Unfortunately, the VxWorks documentation is rather terse on some
behavioural aspects, and I have no VxWorks target at hand to test and check
them. Therefore, I definitely need help from people reading this list who
also happen to be VxWorks users, for providing the following missing bits
of information:

- How does taskName() behave when passed a null task id? Is it equivalent
to specifying taskIdSelf(), or does it lead to a NULL error return?


It behaves like taskName(taskIdSelf()). see vx_skin.c.
Output was
- vx_skin_test_1

myTaskName is 0xf40500 tShell
value = 31 = 0x1f



- How does msgQSend() behave when passed an invalid message priority, i.e.
neither MSG_PRI_NORMAL nor MSG_PRI_URGENT?


It doesn't care (see pMsgQue.cpp).
Output was
- test_init
task1 started
endTime   1834779057842028544
startTime 1832156649595338752
diff  2622408246689792 2622408246689 microSecs per run 26224082466
task1 nrQuestions 100 nrAnswers 100 nrSwitches 100
value = 0 = 0x0


- How does taskInit() behave when passed an invalid set of task options?
Are the invalid flags ignored, or does the routine return an error status?


All invalid bits arg ignored, no error returned. see vx_skin.c.
Output was:
- vx_skin_test_2

taskInit status is 0

taskOptionGet returns 0 is -1
value = 31 = 0x1f 


If you happen to have a VxWorks target at hand regardless of the
architecture, and are willing to help improving the behavioural correctness
of the VxWorks skin, then your input will be most welcome.


Hope this help. Please feel free to ask for more tests.


Great, I will fix the skin using this information. Thanks.


What about a vxWorks test suite? I would like to contribute to it.


You would be most welcome doing so.

 (At least

as soon as I have a working Xenomai environment again.)

 And I would be much
more confident to recommend Xenomai if it had test suites for its various 
skins. I hope to be able to make some contributions once I get approval to 
put a few of our internal test routines available under a free license.




The most useful way to help would be to develop the testsuite for validating the 
recent evolution of the VxWorks skin, which now has a fully native call interface 
from user-space, i.e. it does not need the UVM layer anymore, albeit the former 
way will still be available. Let me know whenever you want to help this way, so 
that we could synchronize, for a better efficiency in fixing the potential issues.



Best regards

Niklaus Giger




/*
 * Copyright (C) 2005 Niklaus Giger [EMAIL PROTECTED].
 *
 * vxWorks is a registered trademark of Wind River Systems, Inc.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
 *
 * Hopefully this program lets you compare the relative performance of
 * taskSwitches and message passing between an original vxWorks image and
 * a xenomai based port.
 */

#ifdef XENOMAI
#include xeno_config.h
#include vxworks/vxworks.h
#include xenomai/timer.h
MODULE_LICENSE(GPL);
#else
#include vxWorks.h
#include stdio.h
#include msgQLib.h
#include taskLib.h
#include sysLib.h
#include arch/ppc/vxPpcLib.h
#define xnprintf printf
#define taskExit exit
#define RTIME UINT64
RTIME rt_timer_tsc();

RTIME rt_timer_tsc()
{
   UINT32 low, high;
   UINT64 res;
   vxTimeBaseGet (low, high);
   res = (UINT64) low + ((UINT64) high)32;
   return res;
}
#endif


#define TASK_PRI115
#define STACK_SIZE  8192

MSG_Q_ID question_qid, answer_qid;

int producer_tid,
   consumer_tid,
   test_tid;
static int nrQuestions;
static int nrAnswers;
static int nrSwitches;
void reportState(const char *where)
{
  xnprintf(%s nrQuestions %d nrAnswers %d nrSwitches %d\n,
   where, nrQuestions, nrAnswers, nrSwitches);
}

#define NR_RUNS 100
void task1 (int a0, int a1, int a2, int a3, int a4,

Re: [Xenomai-core] VxWorks skin improvement

2006-03-17 Thread Philippe Gerum


Alessandro Pittaluga wrote:
Philippe, 
Here follow some tests carried on by my SW lab.

Hoping this may help.



It does, and confirms the other inputs I've had recently on these issues.

Ok, problem solved. Thanks to everyone who helped out.


Regards

Alessandro

ANSWER 1
As shown below calling taskName with a null argument will return the
same result returned by taskName called with the return value of
taskIdSelf().
OUTPUT:
Spawned task xeno_test taskId=0x01a59a48
This is task_entry_pnt() of task 0x01a59a48
taskName(0)=xeno_test  taskName(taskIdSelf())=xeno_test
taskName(0x01a59a48)=xeno_test


ANSWER 2
MSG_PRI_NORMAL is defined 0 and MSG_PRI_URGENT is defined 1. It seems
that all non 0 priority
messages are managed as urgent. The first message extracted from the
queue by a receiver is
the last inserted into the queue with a non 0 priority.
The following 7 cases show the calling sequence of a sending task and
the received message
lengths of a receiving task.

CASE 1
[Sending task]: [msgQSend(qid,a , 1, NO_WAIT, 
MSG_PRI_NORMAL)] returned OK
[Sending task]: [msgQSend(qid,ab, 2, NO_WAIT, 
MSG_PRI_URGENT)] returned OK
[Sending task]: [msgQSend(qid,abc   , 3, NO_WAIT, 2)] returned OK
[Sending task]: [msgQSend(qid,abcd  , 4, NO_WAIT, 3)] returned OK
[Sending task]: [msgQSend(qid,abcde , 5, NO_WAIT, 4)] returned OK
[Sending task]: [msgQSend(qid,abcdef, 6, NO_WAIT, 5)] returned OK
[Sending task]: [msgQSend(qid,abcdefg   , 7, NO_WAIT, 6)] returned OK
[Sending task]: [msgQSend(qid,abcdefgh  , 8, NO_WAIT, 7)] returned OK
[Sending task]: [msgQSend(qid,abcdefghi , 9, NO_WAIT, 8)] returned OK
[Sending task]: [msgQSend(qid,abcdefghij,10, NO_WAIT, 9)] returned OK

[Receiving task]: Received 10 bytes from queue
[Receiving task]: Received  9 bytes from queue
[Receiving task]: Received  8 bytes from queue
[Receiving task]: Received  7 bytes from queue
[Receiving task]: Received  6 bytes from queue
[Receiving task]: Received  5 bytes from queue
[Receiving task]: Received  4 bytes from queue
[Receiving task]: Received  3 bytes from queue
[Receiving task]: Received  2 bytes from queue
[Receiving task]: Received  1 bytes from queue

CASE 2
[Sending task]: [msgQSend(qid,abcdefghij,10, NO_WAIT, 9)] returned OK
[Sending task]: [msgQSend(qid,abcdefghi , 9, NO_WAIT, 8)] returned OK
[Sending task]: [msgQSend(qid,abcdefgh  , 8, NO_WAIT, 7)] returned OK
[Sending task]: [msgQSend(qid,abcdefg   , 7, NO_WAIT, 6)] returned OK
[Sending task]: [msgQSend(qid,abcdef, 6, NO_WAIT, 5)] returned OK
[Sending task]: [msgQSend(qid,abcde , 5, NO_WAIT, 4)] returned OK
[Sending task]: [msgQSend(qid,abcd  , 4, NO_WAIT, 3)] returned OK
[Sending task]: [msgQSend(qid,abc   , 3, NO_WAIT, 2)] returned OK
[Sending task]: [msgQSend(qid,ab, 2, NO_WAIT, 
MSG_PRI_URGENT)] returned OK
[Sending task]: [msgQSend(qid,a , 1, NO_WAIT, 
MSG_PRI_NORMAL)] returned OK

[Receiving task]: Received  2 bytes from queue
[Receiving task]: Received  3 bytes from queue
[Receiving task]: Received  4 bytes from queue
[Receiving task]: Received  5 bytes from queue
[Receiving task]: Received  6 bytes from queue
[Receiving task]: Received  7 bytes from queue
[Receiving task]: Received  8 bytes from queue
[Receiving task]: Received  9 bytes from queue
[Receiving task]: Received 10 bytes from queue
[Receiving task]: Received  1 bytes from queue

CASE 3
[Sending task]: [msgQSend(qid,abcdef,6, NO_WAIT, 5)] returned OK
[Sending task]: [msgQSend(qid,abcdefgh  ,8, NO_WAIT, 7)] returned OK

[Receiving task]: Received  8 bytes from queue
[Receiving task]: Received  6 bytes from queue

CASE 4
[Sending task]: [msgQSend(qid,abcdefgh  ,8, NO_WAIT, 7)] returned OK
[Sending task]: [msgQSend(qid,abcdef,6, NO_WAIT, 5)] returned OK

[Receiving task]: Received  6 bytes from queue
[Receiving task]: Received  8 bytes from queue

CASE 5
[Sending task]: [msgQSend(qid,abcdef,6, NO_WAIT, 5)] returned OK
[Sending task]: [msgQSend(qid,a ,1, NO_WAIT, MSG_PRI_NORMAL)] 
returned OK
[Sending task]: [msgQSend(qid,abcdefgh  ,8, NO_WAIT, 7)] returned OK

[Receiving task]: Received  8 bytes from queue
[Receiving task]: Received  6 bytes from queue
[Receiving task]: Received  1 bytes from queue

CASE 6
[Sending task]: [msgQSend(qid,abcdef,6, NO_WAIT, 5)] returned OK
[Sending task]: [msgQSend(qid,a ,1, NO_WAIT, MSG_PRI_NORMAL)] 
returned OK
[Sending task]: [msgQSend(qid,ab,2, NO_WAIT,-1)] returned OK

Re: [Xenomai-core] broken svn

2006-03-17 Thread Philippe Gerum


Jan Kiszka wrote:

Hi,

latest src/skin/uvm and src/skin/vxworks doesn't build. Work in progress
or broken check-in?


Work in slow progress.



Jan





___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core



--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] broken svn

2006-03-17 Thread Philippe Gerum


Jan Kiszka wrote:

Hi,

latest src/skin/uvm and src/skin/vxworks doesn't build. Work in progress
or broken check-in?


Should be ok now.



Jan





___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core



--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] broken svn

2006-03-17 Thread Jan Kiszka

Philippe Gerum wrote:
 Jan Kiszka wrote:
 Hi,

 latest src/skin/uvm and src/skin/vxworks doesn't build. Work in progress
 or broken check-in?
 
 Should be ok now.

Almost:
intLib.c:21:26: error: vxworks/defs.h: No such file or directory

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] broken svn

2006-03-17 Thread Philippe Gerum


Jan Kiszka wrote:

Philippe Gerum wrote:


Jan Kiszka wrote:


Hi,

latest src/skin/uvm and src/skin/vxworks doesn't build. Work in progress
or broken check-in?


Should be ok now.



Almost:
intLib.c:21:26: error: vxworks/defs.h: No such file or directory



Did you resync your auto-stuff?


Jan




--

Philippe.

___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] broken svn

2006-03-17 Thread Jan Kiszka

Philippe Gerum wrote:
 Jan Kiszka wrote:
 Philippe Gerum wrote:

 Jan Kiszka wrote:

 Hi,

 latest src/skin/uvm and src/skin/vxworks doesn't build. Work in
 progress
 or broken check-in?

 Should be ok now.


 Almost:
 intLib.c:21:26: error: vxworks/defs.h: No such file or directory

 
 Did you resync your auto-stuff?

A simple configure re-run didn't help, but after deleting the build
directory it's fine now. End of warning.

Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

[Xenomai-core] O(1) scheduler broken

2006-03-17 Thread Jan Kiszka

Hi,

I just wanted to test how much the worst-cast jitters improve when
running multiple timed threads over the O(1) scheduler instead of the
default one. Unfortunately, it already crashes my box with the standard
latency test. All debug stuff on and serial console attached still does
not give any output. Looks like a really fatal scheduler crash. :(

Anyone any ideas?
Jan



signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Re: [Xenomai-core] VxWorks skin improvement

[Xenomai-core] [RFC][PATCH] security check for skin access

Re: [Xenomai-core] [RFC][PATCH] security check for skin access

Re: [Xenomai-core] [RFC][PATCH] security check for skin access

Re: [Xenomai-core] VxWorks skin improvement

Re: [Xenomai-core] VxWorks skin improvement

Re: [Xenomai-core] broken svn

Re: [Xenomai-core] broken svn

Re: [Xenomai-core] broken svn

Re: [Xenomai-core] broken svn

Re: [Xenomai-core] broken svn

[Xenomai-core] O(1) scheduler broken

12 matches

Site Navigation

Mail list logo

Footer information