Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
The automated chart seems exactly the thing for me (I have some testing tools development experience). I'll look into it and will soon send a initial design. Of course any pinters/advice/suggestions will be highly appreciated. Philippe Gerum wrote: On Tue, 2007-09-04 at 00:04 +0300, Ravid Baruch Naali wrote: I imagined thats the policy. But is it worth investing time in? or is there higher priority task I can be assigned to? I don't think RTP is high priority for now. Two other tasks would have a much more significant impact, both for Xenomai users and developers. 1) Make Valgrind usable with Xenomai apps; of course without any real-time guarantee anymore, but this would nevertheless plug a serious hole in the development toolset available to users. 2) We do, certainly, definitely, desperately miss an automated way to get performance charts for a few selected Xenomai tests, which would allows us to conduct comparative analysis between versions, and find out what's right or wrong with our changes. For instance, we are currently maintaining seven architecture ports; each time something changes in some part of Xenomai's generic code, we have no freaking idea whether all archs benefit from such change, or if at least no arch gets penalized by it. And the very same goes for the interrupt pipeline, for which any hazardous change may generate adverse effects on an even much larger scale. Let me put this bluntly: this won't fly much longer; we are losing precious time getting rid of any regression way after it has actually happened into the code, because we cannot easily and routinely COMPARE how different versions behave. Aside of this, we don't have any factual data regarding how Xenomai evolved over time in terms of latency, code footprints and so on. What we need is a simple automated way to a given test on any given Xenomai version (actually a SVN commit number would be much better) extracted from our repository, draw a few charts summing up the results, and move those results to our website periodically or even as soon as they are available. _This_ would help users to understand the current trend and why we did some changes (or why we should not have done them), and allow developers to pull the brake each time a serious regression is visible from those charts. Simple and easy: TEST/x86: interrupt latency to kernel handler [latency -t2] (latency in us) ^ |x (XX us) = Houston, we have a problem. | x (ZZ us) | | x (YY us) | +--- commit#72 ...commit#2004 commit#any (v2.0) (v2.3) Another test could analyse the task dispatch latency, another one the code footprints in kernel space, and so on. Once this framework is available, we would find the various hardware to run the tests on and get the results from, that is not an issue anymore. Besides, tackling this issue is quite a good way to have his feet wet almost immediately with the Xenomai framework as a power user, and also to get immediate reward for such work, since we would push its results online routinely. Please, somebody implement this, damnit! Or I'm going to rewrite the entire Xenomai stack in Bourne shell with Java applets for speedups, so you could not complain about bad latencies and unwanted overhead anymore. Thank you, Philippe Gerum wrote: On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote: Hello again, Preface: As of VxWorks 6.x vxworks implement RTP which is an implementation of user space processes with real time capabilities, which of course include an extended API, which from my testings I discovered that we do not support yet. Currently extending the VxWorks API is not in Xenomai task list, does it have any demand? If I'll take it as a my task, do we have any legal issues with using Wind River's headers? This matter is muddy; fair use, interoperability, and copyrights of header files and/or their contents is a legal mess. Our policy is simple: paste-copy of any portion of any proprietary licensed header is unwanted and will be systematically rejected. You need to implement your own header, defining what you need for satisfying all the references within the emulator your are writing from scratch. You should also explicitly mention in the copyright notice that the resulting software is an emulator. We claim to mimick the original software as correctly as possible, according to the API specs which have been made publically available by the copyright holder of the original work, with all the limitations inherent to such exercise. In any case, we don't claim to produce a copy of the original software we only emulate. In short, Xenomai is a Chameleon, not a clone
[Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
Hello again, Preface: As of VxWorks 6.x vxworks implement RTP which is an implementation of user space processes with real time capabilities, which of course include an extended API, which from my testings I discovered that we do not support yet. Currently extending the VxWorks API is not in Xenomai task list, does it have any demand? If I'll take it as a my task, do we have any legal issues with using Wind River's headers? If any of my assumptions is false or if you have any comment/answers please reply. thanks Ravid -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] [PATCH] VxWorks semaphore usage demo
Hello again,
I'm not sure what is the preferred way to commit my changes, so before I
commit i'm Attaching my patch in order to get you remarks and further
instructions
Thanks
--
Ravid Baruch Naali
[EMAIL PROTECTED]
+972 4 6732729
+972 52 5830021
Index: ksrc/skins/vxworks/demos/sem.c
===
--- ksrc/skins/vxworks/demos/sem.c (revision 0)
+++ ksrc/skins/vxworks/demos/sem.c (revision 0)
@@ -0,0 +1,104 @@
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/types.h
+#include sys/wait.h
+#include errno.h
+#include vxworks/vxworks.h
+#include sys/mman.h
+
+
+#define TASK_NUM 10
+#define STACK_SIZE 1024
+#define xnarch_printf printf
+
+SEM_ID semID, syncSEM;
+
+void taskMain(long arg1, long arg2, long arg3, long arg4, long arg5, long arg6, long arg7, long arg8, long arg9, long arg10)
+{
+int localerrno;
+//Waiting to start synchronized with all other spawned tasks
+semTake(syncSEM, WAIT_FOREVER);
+//Taking the counting semaphore to indicate task started running,
+//stall main from exiting
+STATUS result = semTake(semID, WAIT_FOREVER);
+//Chaking for failures
+if(result == ERROR){
+ localerrno = errnoGet();
+ //checking failure reason
+ switch(localerrno){
+ case S_objLib_OBJ_ID_ERROR:
+ xnprintf( Semaphore ID is invalid\n);
+ break;
+ case S_objLib_OBJ_UNAVAILABLE:
+ xnprintf( Semaphore unavailable (NO_WAIT)\n);
+ break;
+ case S_objLib_OBJ_TIMEOUT:
+ xnprintf( Timeout occured before semaphore was released\n);
+ break;
+ case S_semLib_INVALID_OPTION:
+ xnprintf( Semaphore type is invalid\n);
+ break;
+ case EINTR:
+ xnprintf( Received interup\n);
+ break;
+ default:
+ break;
+ }
+ return;
+}
+
+int i = 10;
+//Getting this task's ID
+int ownID = taskIdSelf();
+//Getting this task's pririty
+int priority;
+result = taskPriorityGet(ownID, priority);
+
+xnprintf( My priority is %d\n, priority);
+while(i){
+ printf(My name is %s my tid=%d\n, taskName(ownID), ownID);
+ sleep(1);
+ i--;
+}
+//Signaling main that this task as finished
+semGive(semID);
+//Not realy required but releasing semaphore
+semGive(syncSEM);
+}
+
+
+int main(int argc, char **argv)
+{
+
+mlockall(MCL_CURRENT|MCL_FUTURE);
+int tidStat;
+int tids[TASK_NUM];
+//Creating counting semaphore on which main waits until all tasks are done
+semID = semCCreate(SEM_Q_PRIORITY, TASK_NUM);
+if(!semID){
+ xnprintf( Failed to create semaphore\n);
+ exit(1);
+}
+//Creating a binary semaphore to sync all tasks
+syncSEM = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY);
+if(!syncSEM){
+ xnprintf( Failed to create binary semaphore\n);
+ exit(1);
+}
+//creating all the tasks
+int i;
+for(i = 0; i TASK_NUM; i++){
+ tids[i] = taskSpawn(NULL, 25-i, 0, STACK_SIZE , taskMain,0,0,0,0,0,0,0,0,0,0);
+ xnprintf( Spawned task: %d\n, tids[i]);
+}
+//Giving all tasks a signal to start
+semFlush(syncSEM);
+//Waiting for all task to complete their main routine
+semTake(semID, WAIT_FOREVER);
+for(i = 0; i TASK_NUM; i++)
+ taskDelete(tids[i]);
+semDelete(semID);
+semDelete(syncSEM);
+}
Index: ksrc/skins/vxworks/demos/Makefile
===
--- ksrc/skins/vxworks/demos/Makefile (revision 2960)
+++ ksrc/skins/vxworks/demos/Makefile (working copy)
@@ -7,7 +7,7 @@
STD_CFLAGS := $(shell $(XENO_CONFIG) --xeno-cflags)
STD_LDFLAGS := $(shell $(XENO_CONFIG) --xeno-ldflags) -lvxworks
-STD_TARGETS := satch
+STD_TARGETS := satch sem
GCIC := $(prefix)/bin/gcic
SIM_CFLAGS := -g
@@ -27,6 +27,9 @@
satch: satch.c
$(CC) -o $@ $ $(STD_CFLAGS) $(STD_LDFLAGS)
+sem: sem.c
+ $(CC) -o $@ $ $(STD_CFLAGS) $(STD_LDFLAGS)
+
satch_sim: satch_sim.o
$(GCIC) -o $@ $ $(SIM_LDFLAGS)
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
Philippe Gerum wrote: On Mon, 2007-09-03 at 17:32 +0200, Gilles Chanteperdrix wrote: On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote: Hello again, Hi, I'm not sure what is the preferred way to commit my changes, so before I commit i'm Attaching my patch in order to get you remarks and further instructions The synchronization on tasks completion with the semID semaphore seems broken. The main thread will get the semahore when the first task completes, not when all the tasks complete. I see too many comments, for instance: // Checking for failures if (error == ERROR) is useless, it is pretty obvious from reading the code that you are checking for failure. Comments should tell us things that are not obvious. Now, about the style, this is C code, so use C style comments. I would also prefer that you use the kernel coding style, but this is not kernel code, so I am not sure the rule is to use the kernel coding style. It is. We do want a common style regardless of the execution space. TIA, Thanks for the comments I'll adapt and fix it before I'll send it again. -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] [PATCH] VxWorks semaphore usage demo
Re sending the patch following Gilles comments
Gilles Chanteperdrix wrote:
On 9/3/07, Ravid Baruch Naali [EMAIL PROTECTED] wrote:
Hello again,
Hi,
I'm not sure what is the preferred way to commit my changes, so before I
commit i'm Attaching my patch in order to get you remarks and further
instructions
The synchronization on tasks completion with the semID semaphore seems
broken. The main thread will get the semahore when the first task
completes, not when all the tasks complete.
I see too many comments, for instance:
// Checking for failures
if (error == ERROR)
is useless, it is pretty obvious from reading the code that you are
checking for failure. Comments should tell us things that are not
obvious.
Now, about the style, this is C code, so use C style comments. I would
also prefer that you use the kernel coding style, but this is not
kernel code, so I am not sure the rule is to use the kernel coding
style.
--
Ravid Baruch Naali
[EMAIL PROTECTED]
+972 4 6732729
+972 52 5830021
Index: ksrc/skins/vxworks/demos/sem.c
===
--- ksrc/skins/vxworks/demos/sem.c (revision 0)
+++ ksrc/skins/vxworks/demos/sem.c (revision 0)
@@ -0,0 +1,138 @@
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include unistd.h
+#include sys/types.h
+#include sys/wait.h
+#include errno.h
+#include vxworks/vxworks.h
+#include sys/mman.h
+
+
+#define TASK_NUM 10
+#define STACK_SIZE 1024
+#define LOOPS 10
+#define xnarch_printf printf
+#define TOP_PRIORITY 25
+
+SEM_ID task_counter_sem;
+SEM_ID task_sync_sem;
+
+static errno_to_messgae(char *failing_func);
+
+/*
+ * A shared main routine for all tasks other then the main
+ * each task waits for the signal from the main task
+ * then it notify it's existing
+ *
+ * It then loops and prints out LOOPS times it's name and tid
+ * when done it notifies
+ *
+ * None of the parameters are being used
+ */
+void task_main_routine(long arg1, long arg2, long arg3, long arg4, long arg5, long arg6,
+ long arg7, long arg8, long arg9, long arg10)
+{
+ int localerrno;
+ STATUS result;
+ int priority;
+ int i = LOOPS;
+ int ownID = taskIdSelf();
+
+ /*Waiting to start synchronized with all other spawned tasks*/
+ result = semTake(task_sync_sem, WAIT_FOREVER);
+ if (result == ERROR) {
+ errno_to_messgae(semTake counter);
+ return;
+ }
+ /*Taking the counting semaphore to indicate task started running stall
+ * main from exiting */
+ result = semTake(task_counter_sem, WAIT_FOREVER);
+ if (result == ERROR) {
+ errno_to_messgae(semTake counter);
+ return;
+ }
+ result = taskPriorityGet(ownID, priority);
+
+ xnprintf( Task priority is %d\n, priority);
+ while (i) {
+ xnprintf(Task name is %s tid=%d\n, taskName(ownID), ownID);
+ sleep(1);
+ i--;
+ }
+ /*Signaling this task is done*/
+ semGive(task_counter_sem);
+}
+
+/*
+ * Main task:
+ * spawns TASK_NUM tasks synchronize their operation
+ * exit and clean up when all tasks are done
+ */
+int main(int argc, char **argv)
+{
+ /*array holding all tasks ids*/
+ int tids[TASK_NUM];
+ int i;
+ mlockall(MCL_CURRENT|MCL_FUTURE);
+ /* counting semaphore inital value set to the number of tasks*/
+ task_counter_sem = semCCreate(SEM_Q_PRIORITY, TASK_NUM);
+ if (!task_counter_sem) {
+ xnprintf( Failed to create semaphore\n);
+ exit(1);
+ }
+ /* semaphore to synchronize all task operation */
+ task_sync_sem = semBCreate(SEM_Q_PRIORITY, SEM_EMPTY);
+ if (!task_sync_sem) {
+ xnprintf( Failed to create binary semaphore\n);
+ exit(1);
+ }
+ for (i = 0; i TASK_NUM; i++) {
+ tids[i] = taskSpawn(NULL, (TOP_PRIORITY - i), 0, STACK_SIZE ,
+task_main_routine,0,0,0,0,0,0,0,0,0,0);
+ xnprintf( Spawned task: %d\n, tids[i]);
+ }
+ /* Signaling all tasks to run */
+ semFlush(task_sync_sem);
+ /* Waiting for all task to complete their main routine */
+ for (i = 0; i TASK_NUM; i++)
+ semTake(task_counter_sem, WAIT_FOREVER);
+ /* Cleanup */
+ for (i = 0; i TASK_NUM; i++)
+ taskDelete(tids[i]);
+ semDelete(task_counter_sem);
+ semDelete(task_sync_sem);
+}
+
+
+/*
+ * Prints out the meaning of an error with relation to the failing function
+ *
+ * parameter:
+ * a prefix string to the failure reason
+ */
+static errno_to_messgae(char *failing_func)
+{
+ int localerrno = errnoGet();
+ xnprintf(%s: , failing_func);
+ switch(localerrno){
+ case S_objLib_OBJ_ID_ERROR:
+ xnprintf( Semaphore ID is invalid\n);
+ break;
+ case S_objLib_OBJ_UNAVAILABLE:
+ xnprintf( Semaphore unavailable (NO_WAIT)\n);
+ break;
+ case S_objLib_OBJ_TIMEOUT:
+ xnprintf( Timeout occured before semaphore was
+ released\n);
+ break;
+ case S_semLib_INVALID_OPTION:
+ xnprintf( Semaphore type is invalid\n);
+ break;
+ case EINTR:
+ xnprintf( Received interup\n);
+ break;
+ default:
+ break;
+ }
+}
Index: ksrc/skins/vxworks/demos/Makefile
===
--- ksrc/skins/vxworks/demos/Makefile (revision 2960)
+++ ksrc/skins
Re: [Xenomai-core] VxWorks skin is missing new VxWorks headers for RTP
I imagined thats the policy. But is it worth investing time in? or is there higher priority task I can be assigned to? Philippe Gerum wrote: On Mon, 2007-09-03 at 17:05 +0300, Ravid Baruch Naali wrote: Hello again, Preface: As of VxWorks 6.x vxworks implement RTP which is an implementation of user space processes with real time capabilities, which of course include an extended API, which from my testings I discovered that we do not support yet. Currently extending the VxWorks API is not in Xenomai task list, does it have any demand? If I'll take it as a my task, do we have any legal issues with using Wind River's headers? This matter is muddy; fair use, interoperability, and copyrights of header files and/or their contents is a legal mess. Our policy is simple: paste-copy of any portion of any proprietary licensed header is unwanted and will be systematically rejected. You need to implement your own header, defining what you need for satisfying all the references within the emulator your are writing from scratch. You should also explicitly mention in the copyright notice that the resulting software is an emulator. We claim to mimick the original software as correctly as possible, according to the API specs which have been made publically available by the copyright holder of the original work, with all the limitations inherent to such exercise. In any case, we don't claim to produce a copy of the original software we only emulate. In short, Xenomai is a Chameleon, not a clone. If any of my assumptions is false or if you have any comment/answers please reply. thanks Ravid -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Newbies developer instructions
Hello Xenomai-core mailing list, I'm eager to contribute to the Xenomai project, but since I could not find any opened bugs or a detailed task list apart from: http://www.xenomai.org/index.php/TaskMarket I was wondering if there is way for newbies like me to get involved? If any of you can send me a pointer to where should i begin, I will be more then greatful. Regards Ravid -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Newbies developer instructions
Thanks Jan, I'm working on an academic course which I will teach next semester on Real Time system, in which I will bring both VxWorks and Xenomai as Hard RT systems as an example. Therefore it will be only natural for me to work on porting some examples to VxWorks skin at first. My plan is to implement the same operation in few methods: - Using VxWorks skin - Creating a driver (RTDM) - Using POSIX API Then document the Functions flow from the skin/RTDM calls down to the HAL. Nevertheless, _*Paul*_, If I can assist you with the Xenomai LiveCD please contact me and I will be happy to help. As for the test suite I plan to give it as a project to one of my students (What do you think?). As soon as I'll fill Jan Kiszka wrote: Ravid Baruch Naali wrote: Hello Xenomai-core mailing list, I'm eager to contribute to the Xenomai project, but since I could not find any opened bugs or a detailed task list apart from: http://www.xenomai.org/index.php/TaskMarket I was wondering if there is way for newbies like me to get involved? If any of you can send me a pointer to where should i begin, I will be more then greatful. Über-cool - someone looking for work! :) There are a thousand things to do. The most productive things are likely those you stumble over when using Xenomai in your project. What is not working? What could be solved better or should be added? Also: What features should be checked against regressions while the development advances (more automatic test cases - very important!)? Besides this, here are some more potential points to start with: o https://mail.gna.org/public/xenomai-core/2007-08/msg00017.html :) o Write more examples/tutorials for your favourite skin (see examples repos in SVN). o Check the code against its (doxygen) documentation - everything still up-to-date? Something yet undocumented? o Work with Paul Corner ([EMAIL PROTECTED]) on some regularly updated Xenomai LiveCD (I guess he would be happy about help). o Enhance the testsuite / test script to collect more data, and specifically to evaluate the data more systematically (up to re-creating something like http://issaris.org/rtai/summary.php). To start with: I once had the idea to create some statistics collection library for the testsuite so that all tests could use the same infrastructure to process/visualise benchmark results. o ... (things I forgot) Jan -- Ravid Baruch Naali [EMAIL PROTECTED] +972 4 6732729 +972 52 5830021 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
