Re: [Xenomai-help] compilation problems

2012-01-04 Thread Thomas De Schampheleire 
On Wed, Jan 4, 2012 at 1:22 PM, Daniele  wrote:
> I'm trying to compile an example of Xenomai, but gives me this error:
>
> /usr/bin/ld : cannot find -lrtdk

You will have to provide more information than this.
The error is clear: it cannot find librtdk.so.

Did you already compile the Xenomai userspace libraries? You can't
compile an example without doing that.

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

Re: [Xenomai-help] Xenomai-forge: SEGFAULT is pSOS skin

2011-11-18 Thread Thomas De Schampheleire 
On Tue, Nov 1, 2011 at 12:52 PM, Philippe Gerum  wrote:
> On 09/26/2011 11:11 PM, Philippe Gerum wrote:
>>
>> On Mon, 2011-09-26 at 22:01 +0200, Ronny Meeus wrote:
>>>
>>> On Mon, Sep 26, 2011 at 12:46 PM, Philippe Gerum  wrote:

 On Fri, 2011-09-23 at 22:23 +0200, Philippe Gerum wrote:
>
> On Fri, 2011-09-23 at 22:21 +0200, Ronny Meeus wrote:
>>
>> On Fri, Sep 23, 2011 at 3:00 PM, Philippe Gerum
>>  wrote:
>>>
>>> On Thu, 2011-09-22 at 22:15 +0200, Ronny Meeus wrote:

 Hello

 I have created some time ago a test application for the PSOS
 interface
 of Xenomai.
 This is a extensive test that stresses most of the PSOS services we
 use in our application. You can find it as an attachment.
 It is running fine on Xenomai 2-5-6.
 Note that in the test application there is also a benchmarking part.
 This is currently disabled, I will fix that later.

 Now I'm investigating a switch to xenomai-forge so I tried to run
 the
 same test on this platform.
>>>
>>> This is a double cleanup call, due to the incorrect propagation of an
>>> internal error detected in the task trampoline within the psos
>>> emulator.
>>> In fact, this reveals a more general shortcoming with handling this
>>> situation for tasks, and this may also reveal an issue with
>>> t_delete()
>>> over the Mercury core.
>>>
>>> I can't reproduce the issue here with your test program, but I'm sure
>>> something is wrong in the emulator anyway, I'm just lucky with the
>>> timings. Since you are running over the vanilla kernel and maybe x86,
>>> you could run valgrind to check whether some memory corruption is
>>> detected.
>>>
>>> I'm working on this bug which will bite any emulator based on the
>>> copperplate interface the same way. I don't see any show stopper to
>>> fix
>>> it, but this needs some thoughts to do this properly.
>>>
>>> Btw,
>>>
>>> - what is your architecture?
>>> - what is your glibc version?
>>
>> Running on a PC (virtual BOX).
>>
>> This is the information about the lib I use:
>> meeusr@meeusr-laptop:/lib$ ./libc.so.6
>> GNU C Library (Ubuntu EGLIBC 2.11.1-0ubuntu7.6) stable release version
>> 2.11.1, by Roland McGrath et al.
>> Copyright (C) 2009 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.
>> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>> PARTICULAR PURPOSE.
>> Compiled by GNU CC version 4.4.3.
>> Compiled on a Linux>>2.6.24-27-server<<  system on 2010-11-17.
>> Available extensions:
>>     crypt add-on version 2.1 by Michael Glad and others
>>     GNU Libidn by Simon Josefsson
>>     Native POSIX Threads Library by Ulrich Drepper et al
>>     BIND-8.2.3-T5B
>> For bug reporting instructions, please see:
>> .
>>
>>
>> The valgrind stuff I will do later.
>
> I can reproduce now. This is highly timing dependent.
>

 git://git.xenomai.org/xenomai-forge.git has a general fix for this
 issue. Your test code will need the following patch to work. The basic
 fix is that you can't create multiple objects with the same name with
 Xenomai, because we need unique names for the registry to be meaningful.
>>>
>>> Thanks for looking into this issue.
>>> The problem that we have is that we have a huge application and we
>>> cannot guarantee that all tasknames are unique.
>>> That is why I have implemented a mechanism to make a taskname unique
>>> (I already had this in the Xenomai-2.5.6). In the force version this
>>> could be something like:
>>>
>>>         if (name == NULL || *name == '\0')
>>>                 sprintf(task->name, "t%lu", ++anon_tids);
>>>         else {
>>>                 struct clusterobj *cobj =
>>> cluster_findobj(&psos_task_table, name);
>>>                 if (cobj != NULL) {
>>>                         snprintf(task->name,sizeof(task->name),
>>> "%s@%lu", name, ++anon_tids);
>>>                 }
>>>                 else
>>>                         strncpy(task->name, name, sizeof(task->name));
>>>                 task->name[sizeof(task->name) - 1] = '\0';
>>>         }
>>>
>>> This is an example for tasks. The same could be done for
>>> regions,semaphores and message queues. I tried it on my repo and the
>>> task application (rtprint) runs unmodified.
>>> The only issue I see with this approach is that when 2 tasks with an
>>> identical name, for example TEST, are created, the second one will be
>>> mapped to TEST@1. If a t_ident call is executed, the TID of the first
>>> instance will be returned, which is fine. If now the first task is
>>> deleted, the t_ident call will fail.
>>>
>>
>
> I have committed a general fix for this issue in the -forge

[Xenomai-help] xenomai-forge git woes

2011-11-07 Thread Thomas De Schampheleire 
Hi,

It seems something was up with the Xenomai-forge git repository. On
the web interface, I see many old commits being recommitted today.

Can you give some background information as to why this happened?
And more importantly, not being an experienced git user, how to
recover from it? 'git status' shows:

# On branch master
# Your branch and 'origin/master' have diverged,
# and have 177 and 360 different commit(s) each, respectively.

and a 'git pull' shows tons of conflicts on files I did not touch.

Thanks,
Thomas

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

Re: [Xenomai-help] for helping!

2011-10-27 Thread Thomas De Schampheleire 
Hi,

2011/10/27 白痴一梦 :
> hello experts:
> I am a newer of xenomai.this days I try to build xenomai in archlinux on my
> pc (PD3.4G cpu).i use the version of 2.6.0_rc4 and 2.6.0-rc5 on kernel
> 2.6.38 for many times. all most every time, i built the kernel and user
> space succesfully.(in different /.config files,for total 42 times),but when
> i run the tests in /usr/xenomai/bin,for examples(latency),i got the error :
> xenomai: /dev/rtheap is missing
> (chardev, major=10 minor=254)
> every times.
> i realy do not know how and what to do,why thus?? thank you!

I quote an earlier reply of Gilles on a similar issue:

"You have probably missed the following message when running "make
install":

*** Warning: you are not super-user and sudo does not work, real-time devices
*** nodes will not be created.
*** If you do not create these devices by hand, Xenomai test programs will not
*** work.
*** To create these devices please run "make devices" with super-user
*** privileges."

Best regards,
Thomas

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

Re: [Xenomai-help] [PATCH 0 of 4] xenomai-forge PSOS: miscellaneous fixes

2011-10-26 Thread Thomas De Schampheleire 
On Wed, Oct 26, 2011 at 2:47 PM, Philippe Gerum  wrote:
> On 10/26/2011 11:44 AM, Thomas De Schampheleire wrote:
>>
>> Hi,
>>
>> On Wed, Oct 19, 2011 at 5:02 PM, Thomas De Schampheleire
>>   wrote:
>>>
>>> This patch series includes some misc. fixes to xenomai-forge:
>>>
>>> * definition of ERR_OBJTFULL (should also be added to Xenomai proper)
>>> * port long_names feature to xenomai-forge and fix it
>>> * add tm_getm() function (not present in pSOS but present in Xenomai
>>> proper)
>>> * fix compiler warning in task.c
>>>
>>> Signed-off-by: Thomas De Schampheleire
>>> Signed-off-by: Ronny Meeus
>>>
>>> ---
>>>  include/psos/Makefile.am  |   2 +-
>>>  include/psos/Makefile.in  |   2 +-
>>>  include/psos/long_names.h |  14 ++
>>>  include/psos/psos.h       |   5 +
>>>  lib/psos/init.c           |  15 +++
>>>  lib/psos/pt.c             |   6 ++
>>>  lib/psos/queue.c          |   6 ++
>>>  lib/psos/rn.c             |   5 +
>>>  lib/psos/sem.c            |   6 ++
>>>  lib/psos/task.c           |   9 +++--
>>>  lib/psos/tm.c             |   7 +++
>>>  11 files changed, 73 insertions(+), 4 deletions(-)
>>>
>>>
>>>
>>
>> Do you have any comments on this patch series?
>
>
> Merged as discussed, thanks.

Thanks for implementing the updates.

~Thomas

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

Re: [Xenomai-help] [PATCH 4 of 4] psos: fix compiler warning: cprio could be used uninitialized

2011-10-26 Thread Thomas De Schampheleire 
On Wed, Oct 26, 2011 at 1:58 PM, Philippe Gerum  wrote:
> On 10/26/2011 01:04 PM, Thomas De Schampheleire wrote:
>>
>> On Wed, Oct 26, 2011 at 12:25 PM, Philippe Gerum  wrote:
>>>
>>> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>>>
>>>> Assign default 1 to satisfy compiler (tested with gcc 4.4.3)
>>>>
>>>> Signed-off-by: Thomas De
>>>> Schampheleire
>>>> Signed-off-by: Ronny Meeus
>>>>
>>>> ---
>>>>  lib/psos/task.c |  4 ++--
>>>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/lib/psos/task.c b/lib/psos/task.c
>>>> --- a/lib/psos/task.c
>>>> +++ b/lib/psos/task.c
>>>> @@ -247,7 +247,7 @@ u_long t_create(const char *name, u_long
>>>>        pthread_attr_t thattr;
>>>>        struct syncstate syns;
>>>>        struct service svc;
>>>> -       int ret, cprio;
>>>> +       int ret, cprio = 1;
>>>>        char short_name[5];
>>>>
>>>>        ret = check_task_priority(prio,&cprio);
>>>> @@ -414,7 +414,7 @@ u_long t_resume(u_long tid)
>>>>  u_long t_setpri(u_long tid, u_long newprio, u_long *oldprio_r)
>>>>  {
>>>>        struct psos_task *task;
>>>> -       int ret, cprio;
>>>> +       int ret, cprio = 1;
>>>>
>>>>        task = get_psos_task_or_self(tid,&ret);
>>>>        if (task == NULL)
>>>>
>>>
>>> Looks like 4.4.3 is wrong, 4.4.4+ does it better and does not choke. Just
>>> to
>>> make sure the optimizer is given a chance to see the truth, could you try
>>> without this patch, but with tagging check_task_priority() as inline
>>> instead, with --disable-debug, then with --enable-debug=full switches?
>>
>> Without this patch, inlined check_task_prio, --disable-debug:
>> /bin/sh ../../libtool  --tag=CC   --mode=compile
>>
>> /repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
>> -DHAVE_CONFIG_H -I. -I../../lib/include  -O2 -D_GNU_SOURCE
>> -D_REENTRANT -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes
>> -Wno-long-long -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
>> -Wstrict-prototypes -I../../include   -pipe -Os  -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
>> -MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
>> -f 'task.c' || echo './'`task.c
>> libtool: compile:
>>
>> /repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
>> -DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
>> -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
>> -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
>> -Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
>> -MD -MP -MF .deps/libpsos_la-task.Tpo -c task.c  -fPIC -DPIC -o
>> .libs/libpsos_la-task.o
>> cc1: warnings being treated as errors
>> task.c: In function 't_setpri':
>> task.c:417: error: 'cprio' may be used uninitialized in this function
>> make[3]: *** [libpsos_la-task.lo] Error 1
>>
>> Without this patch, inlined check_task_prio, --enable-debug=full
>> /bin/sh ../../libtool  --tag=CC   --mode=compile
>>
>> /repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
>> -DHAVE_CONFIG_H -I. -I../../lib/include  -g -D__XENO_DEBUG__
>> -D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
>> -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
>> -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
>> -Wstrict-prototypes -I../../include   -pipe -Os  -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
>> -MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
>> -f 'task.c' || echo './'`task.c
>> libtool: compile:
>>
>> /repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
>> -DHAVE_CONFIG_H -I. -I../../lib/include -g -D__XENO_DEBUG__
>> -D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
>> -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
>> -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
>> -Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
>> -MD -MP -M

Re: [Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL

2011-10-26 Thread Thomas De Schampheleire 
Hi,

On Wed, Oct 26, 2011 at 12:33 PM, Philippe Gerum  wrote:
> On 10/26/2011 12:26 PM, Thomas De Schampheleire wrote:
>>
>> Hi,
>>
>> On Wed, Oct 26, 2011 at 12:19 PM, Philippe Gerum  wrote:
>>>
>>> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>>>
>>>> Signed-off-by: Thomas De
>>>> Schampheleire
>>>> Signed-off-by: Ronny Meeus
>>>>
>>>> ---
>>>>  include/psos/psos.h |  1 +
>>>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/include/psos/psos.h b/include/psos/psos.h
>>>> --- a/include/psos/psos.h
>>>> +++ b/include/psos/psos.h
>>>> @@ -97,6 +97,7 @@
>>>>  #define ERR_OBJDEL   0x05
>>>>  #define ERR_OBJID    0x06
>>>>  #define ERR_OBJTYPE  0x07
>>>> +#define ERR_OBJTFULL 0x08
>>>>  #define ERR_OBJNF    0x09
>>>>
>>>>  #define ERR_NOTCB    0x0E
>>>
>>> Where is this error code used in the Xenomai tree? Can't find it right
>>> now.
>>
>> It's not used in the Xenomai code itself, but it may be used by
>> applications.
>> The definition is absent both in Xenomai as Xenomai-forge.
>>
>> ~Thomas
>>
>
> Yes, the point is that so far, only the errors the Xenomai emulation does
> return are mentioned in this file. But we should merge this anyhow, since
> the original *_create() calls could throw this, so the app has to check
> despite Xenomai won't fail this way, right?

Ok, I understand the origin now.
But indeed, as you say, legacy apps may still check for ERR_OBJTFULL
or any other definition that was in the original psos.h, so Xenomai /
Xenomai-forge has to supply these values as well.

~Thomas

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

Re: [Xenomai-help] [PATCH 4 of 4] psos: fix compiler warning: cprio could be used uninitialized

2011-10-26 Thread Thomas De Schampheleire 
On Wed, Oct 26, 2011 at 12:25 PM, Philippe Gerum  wrote:
> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>
>> Assign default 1 to satisfy compiler (tested with gcc 4.4.3)
>>
>> Signed-off-by: Thomas De Schampheleire
>> Signed-off-by: Ronny Meeus
>>
>> ---
>>  lib/psos/task.c |  4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/lib/psos/task.c b/lib/psos/task.c
>> --- a/lib/psos/task.c
>> +++ b/lib/psos/task.c
>> @@ -247,7 +247,7 @@ u_long t_create(const char *name, u_long
>>        pthread_attr_t thattr;
>>        struct syncstate syns;
>>        struct service svc;
>> -       int ret, cprio;
>> +       int ret, cprio = 1;
>>        char short_name[5];
>>
>>        ret = check_task_priority(prio,&cprio);
>> @@ -414,7 +414,7 @@ u_long t_resume(u_long tid)
>>  u_long t_setpri(u_long tid, u_long newprio, u_long *oldprio_r)
>>  {
>>        struct psos_task *task;
>> -       int ret, cprio;
>> +       int ret, cprio = 1;
>>
>>        task = get_psos_task_or_self(tid,&ret);
>>        if (task == NULL)
>>
>
> Looks like 4.4.3 is wrong, 4.4.4+ does it better and does not choke. Just to
> make sure the optimizer is given a chance to see the truth, could you try
> without this patch, but with tagging check_task_priority() as inline
> instead, with --disable-debug, then with --enable-debug=full switches?

Without this patch, inlined check_task_prio, --disable-debug:
/bin/sh ../../libtool  --tag=CC   --mode=compile
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include  -O2 -D_GNU_SOURCE
-D_REENTRANT -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes
-Wno-long-long -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include   -pipe -Os  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
-f 'task.c' || echo './'`task.c
libtool: compile:
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
-Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c task.c  -fPIC -DPIC -o
.libs/libpsos_la-task.o
cc1: warnings being treated as errors
task.c: In function 't_setpri':
task.c:417: error: 'cprio' may be used uninitialized in this function
make[3]: *** [libpsos_la-task.lo] Error 1

Without this patch, inlined check_task_prio, --enable-debug=full
/bin/sh ../../libtool  --tag=CC   --mode=compile
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include  -g -D__XENO_DEBUG__
-D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include   -pipe -Os  -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c -o libpsos_la-task.lo `test
-f 'task.c' || echo './'`task.c
libtool: compile:
/repo/tdescham/reborn/buildroot-forge/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -g -D__XENO_DEBUG__
-D__XENO_DEBUG_FULL__ -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
-Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT libpsos_la-task.lo
-MD -MP -MF .deps/libpsos_la-task.Tpo -c task.c  -fPIC -DPIC -o
.libs/libpsos_la-task.o
cc1: warnings being treated as errors
task.c: In function 't_setpri':
task.c:417: error: 'cprio' may be used uninitialized in this function
make[3]: *** [libpsos_la-task.lo] Error 1


So, debug or not, compiler keeps complaining.
For your  reference, this is the change I did instead of the patch:
diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -228,7 +228,7 @@ int psos_task_normalize_priority(unsigne
return psos_prio;
 }

-static int check_task_priority(u_long psos_prio, int *core_prio)
+static inline int check_task_priority(u_long psos_prio, int *core_prio)
 {
if (psos_prio < 1 || psos_prio > 255) /* In theory. */
return ERR_PRIOR;


powerpc-linux-gcc (crosstool-NG 1.12.1 - buildroot 2011.08-hgc55c56f04355) 4.4.3
Copyrig

Re: [Xenomai-help] [PATCH 3 of 4] psos: add tm_getm function

2011-10-26 Thread Thomas De Schampheleire 
On Wed, Oct 26, 2011 at 12:22 PM, Philippe Gerum  wrote:
> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>
>> Signed-off-by: Thomas De Schampheleire
>> Signed-off-by: Ronny Meeus
>>
>> ---
>>  include/psos/psos.h |  2 ++
>>  lib/psos/tm.c       |  7 +++
>>  2 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/psos/psos.h b/include/psos/psos.h
>> --- a/include/psos/psos.h
>> +++ b/include/psos/psos.h
>> @@ -363,6 +363,8 @@ u_long tm_set(u_long date,
>>              u_long time,
>>              u_long ticks);
>>
>> +u_long tm_getm(unsigned long long *ns);
>> +
>>  u_long tm_wkafter(u_long ticks);
>>
>>  u_long tm_wkwhen(u_long date,
>> diff --git a/lib/psos/tm.c b/lib/psos/tm.c
>> --- a/lib/psos/tm.c
>> +++ b/lib/psos/tm.c
>> @@ -309,3 +309,10 @@ u_long tm_get(u_long *date_r, u_long *ti
>>
>>        return SUCCESS;
>>  }
>> +
>> +u_long tm_getm(unsigned long long *ns_r)
>> +{
>> +       *ns_r = clockobj_get_tsc();
>> +       return SUCCESS;
>> +}
>
> -       *ns_r = clockobj_get_tsc();
> +       *ns_r = clockobj_tsc_to_ns(clockobj_get_tsc());
>

Ok, thanks.

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

Re: [Xenomai-help] [PATCH 2 of 4] psos: port long_names feature to xenomai-forge

2011-10-26 Thread Thomas De Schampheleire 
On Wed, Oct 26, 2011 at 12:21 PM, Philippe Gerum  wrote:
> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>
>> While psos interface accepts 4 character ids, non null terminated,
>> xenomai uses longer ids which must be null terminated. Revert to
>> the behaviour of psos interface, while allowing long id strings if
>> the global variable psos_long_names is set to non-zero.
>>
>> This patch ports the original fix from xenomai to xenomai-forge,
>> fixing following problems:
>> * a bug in __psos_maybe_short_name so that only 3 characters are
>>   retained
>> * the call to __psos_maybe_short_name also needs to be done in the
>>   ident functions
>> * the pt_create and pt_ident functions also need to be adapted
>>
>
> Please merge long_names.h into psos.h, having a separate header for this is
> way overkill and brings nothing.

It avoids exposing an internal interface to applications through psos.h.
If anything, I think we should make a psos_internal.h or whatever,
that can host __psos_maybe_short_name among others.

~Thomas

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

Re: [Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL

2011-10-26 Thread Thomas De Schampheleire 
Hi,

On Wed, Oct 26, 2011 at 12:19 PM, Philippe Gerum  wrote:
> On 10/19/2011 09:35 AM, Thomas De Schampheleire wrote:
>>
>> Signed-off-by: Thomas De Schampheleire
>> Signed-off-by: Ronny Meeus
>>
>> ---
>>  include/psos/psos.h |  1 +
>>  1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/psos/psos.h b/include/psos/psos.h
>> --- a/include/psos/psos.h
>> +++ b/include/psos/psos.h
>> @@ -97,6 +97,7 @@
>>  #define ERR_OBJDEL   0x05
>>  #define ERR_OBJID    0x06
>>  #define ERR_OBJTYPE  0x07
>> +#define ERR_OBJTFULL 0x08
>>  #define ERR_OBJNF    0x09
>>
>>  #define ERR_NOTCB    0x0E
>
> Where is this error code used in the Xenomai tree? Can't find it right now.

It's not used in the Xenomai code itself, but it may be used by applications.
The definition is absent both in Xenomai as Xenomai-forge.

~Thomas

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

Re: [Xenomai-help] [PATCH 0 of 4] xenomai-forge PSOS: miscellaneous fixes

2011-10-26 Thread Thomas De Schampheleire 
Hi,

On Wed, Oct 19, 2011 at 5:02 PM, Thomas De Schampheleire
 wrote:
> This patch series includes some misc. fixes to xenomai-forge:
>
> * definition of ERR_OBJTFULL (should also be added to Xenomai proper)
> * port long_names feature to xenomai-forge and fix it
> * add tm_getm() function (not present in pSOS but present in Xenomai proper)
> * fix compiler warning in task.c
>
> Signed-off-by: Thomas De Schampheleire 
> Signed-off-by: Ronny Meeus 
>
> ---
>  include/psos/Makefile.am  |   2 +-
>  include/psos/Makefile.in  |   2 +-
>  include/psos/long_names.h |  14 ++
>  include/psos/psos.h       |   5 +
>  lib/psos/init.c           |  15 +++
>  lib/psos/pt.c             |   6 ++
>  lib/psos/queue.c          |   6 ++
>  lib/psos/rn.c             |   5 +
>  lib/psos/sem.c            |   6 ++
>  lib/psos/task.c           |   9 +++--
>  lib/psos/tm.c             |   7 +++
>  11 files changed, 73 insertions(+), 4 deletions(-)
>
>
>

Do you have any comments on this patch series?

Thanks,
Thomas

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

[Xenomai-help] forge: license files

2011-10-21 Thread Thomas De Schampheleire 
Hi,

With respect to the source code license of xenomai-forge: there is no
COPYING file in lib/psos, while there is one in most other
subdirectories.
I didn't check all other directories, but I guess you know better than
me where there should be such a file.

Best regards,
Thomas

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

[Xenomai-help] [PATCH 4 of 4] psos: fix compiler warning: cprio could be used uninitialized

2011-10-19 Thread Thomas De Schampheleire 
Assign default 1 to satisfy compiler (tested with gcc 4.4.3)

Signed-off-by: Thomas De Schampheleire 
Signed-off-by: Ronny Meeus 

---
 lib/psos/task.c |  4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -247,7 +247,7 @@ u_long t_create(const char *name, u_long
pthread_attr_t thattr;
struct syncstate syns;
struct service svc;
-   int ret, cprio;
+   int ret, cprio = 1;
char short_name[5];
 
ret = check_task_priority(prio, &cprio);
@@ -414,7 +414,7 @@ u_long t_resume(u_long tid)
 u_long t_setpri(u_long tid, u_long newprio, u_long *oldprio_r)
 {
struct psos_task *task;
-   int ret, cprio;
+   int ret, cprio = 1;
 
task = get_psos_task_or_self(tid, &ret);
if (task == NULL)



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

[Xenomai-help] [PATCH 2 of 4] psos: port long_names feature to xenomai-forge

2011-10-19 Thread Thomas De Schampheleire 
While psos interface accepts 4 character ids, non null terminated,
xenomai uses longer ids which must be null terminated. Revert to
the behaviour of psos interface, while allowing long id strings if
the global variable psos_long_names is set to non-zero.

This patch ports the original fix from xenomai to xenomai-forge,
fixing following problems:
* a bug in __psos_maybe_short_name so that only 3 characters are
  retained
* the call to __psos_maybe_short_name also needs to be done in the
  ident functions
* the pt_create and pt_ident functions also need to be adapted

Signed-off-by: Gilles Chanteperdrix 
Signed-off-by: Thomas De Schampheleire 
Signed-off-by: Ronny Meeus 

---
 include/psos/Makefile.am  |   2 +-
 include/psos/Makefile.in  |   2 +-
 include/psos/long_names.h |  14 ++
 include/psos/psos.h   |   2 ++
 lib/psos/init.c   |  15 +++
 lib/psos/pt.c |   6 ++
 lib/psos/queue.c  |   6 ++
 lib/psos/rn.c |   5 +
 lib/psos/sem.c|   6 ++
 lib/psos/task.c   |   5 +
 10 files changed, 61 insertions(+), 2 deletions(-)

diff --git a/include/psos/Makefile.am b/include/psos/Makefile.am
--- a/include/psos/Makefile.am
+++ b/include/psos/Makefile.am
@@ -1,3 +1,3 @@
 includesubdir = $(includedir)/psos
 
-includesub_HEADERS = psos.h
+includesub_HEADERS = psos.h long_names.h
diff --git a/include/psos/Makefile.in b/include/psos/Makefile.in
--- a/include/psos/Makefile.in
+++ b/include/psos/Makefile.in
@@ -238,7 +238,7 @@ top_build_prefix = @top_build_prefix@
 top_builddir = @top_builddir@
 top_srcdir = @top_srcdir@
 includesubdir = $(includedir)/psos
-includesub_HEADERS = psos.h
+includesub_HEADERS = psos.h long_names.h
 all: all-am
 
 .SUFFIXES:
diff --git a/include/psos/long_names.h b/include/psos/long_names.h
new file mode 100644
--- /dev/null
+++ b/include/psos/long_names.h
@@ -0,0 +1,14 @@
+#ifndef LONG_NAMES_H
+#define LONG_NAMES_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+const char *__psos_maybe_short_name(char shrt[5], const char *lng);
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LONG_NAMES_H */
diff --git a/include/psos/psos.h b/include/psos/psos.h
--- a/include/psos/psos.h
+++ b/include/psos/psos.h
@@ -371,6 +371,8 @@ u_long tm_wkwhen(u_long date,
 
 int psos_task_normalize_priority(unsigned long psos_prio);
 
+extern unsigned psos_long_names;
+
 #ifdef __cplusplus
 };
 #endif /* __cplusplus */
diff --git a/lib/psos/init.c b/lib/psos/init.c
--- a/lib/psos/init.c
+++ b/lib/psos/init.c
@@ -17,6 +17,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "tm.h"
 #include "task.h"
 #include "sem.h"
@@ -34,6 +36,8 @@
 #include "pt.h"
 #include "rn.h"
 
+unsigned psos_long_names;
+
 static unsigned int clock_resolution = 100; /* 1ms */
 
 static const struct option psos_options[] = {
@@ -105,3 +109,14 @@ static __attribute__ ((constructor)) voi
 {
copperplate_register_skin(&psos_skin);
 }
+
+const char *__psos_maybe_short_name(char shrt[5], const char *lng)
+{
+   if (psos_long_names)
+   return lng;
+
+   strncpy(shrt, lng, 5 - 1);
+   shrt[4] = '\0';
+
+   return (const char *)shrt;
+}
diff --git a/lib/psos/pt.c b/lib/psos/pt.c
--- a/lib/psos/pt.c
+++ b/lib/psos/pt.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pt.h"
 
 #define pt_magic   0x8181fefe
@@ -127,6 +128,7 @@ u_long pt_create(const char *name,
u_long overhead;
caddr_t mp;
u_long n;
+   char short_name[5];
 
if ((uintptr_t)paddr & (sizeof(uintptr_t) - 1))
return ERR_PTADDR;
@@ -145,6 +147,7 @@ u_long pt_create(const char *name,
if (name == NULL || *name == '\0')
sprintf(pt->name, "pt%lu", ++anon_ptids);
else {
+   name = __psos_maybe_short_name(short_name, name);
strncpy(pt->name, name, sizeof(pt->name));
pt->name[sizeof(pt->name) - 1] = '\0';
}
@@ -289,10 +292,13 @@ u_long pt_ident(const char *name, u_long
struct pvclusterobj *cobj;
struct service svc;
struct psos_pt *pt;
+   char short_name[5];
 
if (node)
return ERR_NODENO;
 
+   name = __psos_maybe_short_name(short_name, name);
+
COPPERPLATE_PROTECT(svc);
cobj = pvcluster_findobj(&psos_pt_table, name);
COPPERPLATE_UNPROTECT(svc);
diff --git a/lib/psos/queue.c b/lib/psos/queue.c
--- a/lib/psos/queue.c
+++ b/lib/psos/queue.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "reference.h"
 #include "task.h"
 #include "queue.h"
@@ -85,6 +86,7 @@ static u_long __q_create(const char *nam
struc

[Xenomai-help] [PATCH 1 of 4] psos.h: add definition of ERR_OBJTFULL

2011-10-19 Thread Thomas De Schampheleire 
Signed-off-by: Thomas De Schampheleire 
Signed-off-by: Ronny Meeus 

---
 include/psos/psos.h |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/psos/psos.h b/include/psos/psos.h
--- a/include/psos/psos.h
+++ b/include/psos/psos.h
@@ -97,6 +97,7 @@
 #define ERR_OBJDEL   0x05
 #define ERR_OBJID0x06
 #define ERR_OBJTYPE  0x07
+#define ERR_OBJTFULL 0x08
 #define ERR_OBJNF0x09
 
 #define ERR_NOTCB0x0E


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

[Xenomai-help] [PATCH 0 of 4] xenomai-forge PSOS: miscellaneous fixes

2011-10-19 Thread Thomas De Schampheleire 
This patch series includes some misc. fixes to xenomai-forge:

* definition of ERR_OBJTFULL (should also be added to Xenomai proper)
* port long_names feature to xenomai-forge and fix it
* add tm_getm() function (not present in pSOS but present in Xenomai proper)
* fix compiler warning in task.c

Signed-off-by: Thomas De Schampheleire 
Signed-off-by: Ronny Meeus 

---
 include/psos/Makefile.am  |   2 +-
 include/psos/Makefile.in  |   2 +-
 include/psos/long_names.h |  14 ++
 include/psos/psos.h   |   5 +
 lib/psos/init.c   |  15 +++
 lib/psos/pt.c |   6 ++
 lib/psos/queue.c  |   6 ++
 lib/psos/rn.c |   5 +
 lib/psos/sem.c|   6 ++
 lib/psos/task.c   |   9 +++--
 lib/psos/tm.c |   7 +++
 11 files changed, 73 insertions(+), 4 deletions(-)



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

[Xenomai-help] [PATCH 3 of 4] psos: add tm_getm function

2011-10-19 Thread Thomas De Schampheleire 
Signed-off-by: Thomas De Schampheleire 
Signed-off-by: Ronny Meeus 

---
 include/psos/psos.h |  2 ++
 lib/psos/tm.c   |  7 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/psos/psos.h b/include/psos/psos.h
--- a/include/psos/psos.h
+++ b/include/psos/psos.h
@@ -363,6 +363,8 @@ u_long tm_set(u_long date,
  u_long time,
  u_long ticks);
 
+u_long tm_getm(unsigned long long *ns);
+
 u_long tm_wkafter(u_long ticks);
 
 u_long tm_wkwhen(u_long date,
diff --git a/lib/psos/tm.c b/lib/psos/tm.c
--- a/lib/psos/tm.c
+++ b/lib/psos/tm.c
@@ -309,3 +309,10 @@ u_long tm_get(u_long *date_r, u_long *ti
 
return SUCCESS;
 }
+
+u_long tm_getm(unsigned long long *ns_r)
+{
+   *ns_r = clockobj_get_tsc();
+   return SUCCESS;
+}
+


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

Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow

2011-10-12 Thread Thomas De Schampheleire 
Hi,

On Mon, Sep 26, 2011 at 11:46 PM, Gilles Chanteperdrix
 wrote:
> On 09/19/2011 10:45 AM, Thomas De Schampheleire wrote:
>> Hi,
>>
>> On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus  wrote:
>>> On Mon, Sep 19, 2011 at 9:25 AM,   wrote:
>>>>> From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org]
>>>>> On Behalf Of Philippe Gerum
>>>>> Sent: Sunday, September 18, 2011 5:37 PM
>>>>> ...
>>>>> Actually, we used to follow strictly the pSOS convention for this until
>>>>> 2.4.x, at which point we moved to name strings precisely because
>>>>> non-null terminated char[4] arrays would break the registry, the way you
>>>>> described. This is one of the rare situations where mimicking a useless
>>>>> limitation of the original API may be challenged by usability concerns
>>>>> in the new environment, and usability won in that case. The problem
>>>>> mostly comes from the fact that char[4] is automatically convertible to
>>>>> const char *, so we have no warning/error leading us to check the
>>>>> potentially problematic call sites.
>>>>>
>>>>> The concern about moving back to char[4] arrays - null-terminated if
>>>>> shorter - is for people who currently assign strings longer than 4
>>>>> characters to name their objects. What could be done, is providing a
>>>>> build switch to select the accepted input, like
>>>>> --disable-psos-long-names to turn on char[4] interpretation.
>>>>
>>>> While I would prefer the switch --enable-psos-long-names, this sounds okay 
>>>> to me, the more so as it is more than people who use the pSOS skin without 
>>>> obeying pSOS rules deserve.
>>>> --
>> [..]
>>>>
>>>
>>> Another option would be to introduce a run-time switch.
>>> The default behavior could be that long names are supported and if the
>>> "enable_short_names()" function is called, all names will the cut at 4
>>> characters.
>>> The advantage of this dynamic switch is that different applications
>>> using the same library can use the mode they prefer.
>>
>> I would also be in favor of a runtime setting, rather than a
>> compile-time one. One cannot assume that all PSOS applications on a
>> system follow the same rules, or that there cannot be a mix of
>> 'legacy' PSOS applications and 'xenomai-style' ones. According to me,
>> a library should support all these uses.
>
> Hi,
>
> here is a patch which truncates identifiers to four characters and
> terminates them by a '\0' character, in order to avoid the issues at
> the origin of this thread. The patch also adds a variable
> "psos_long_names", 0 by default, which may be set to a non-zero value
> to enable the old behaviour (assume the identifier strings may be
> longer than 4 characters and are already null terminated).
>
> Could someone with the issue test it?

It seems this slipped through the cracks, my apologies. We already
implemented this ourselves similarly, we didn't actually test your
patch so far.

Now that we're trying out xenomai-forge, I ported this patch and tested it.
There are a few problems with it (also relevant to cobalt xenomai)

* a bug in __psos_maybe_short_name so that only 3 characters are
retained (see below)
* the call to __psos_maybe_short_name also needs to be done in the
_ident functions
* although we don't use it, I think the pt_create and pt_ident
functions also need to be adapted

Moreover, I wonder why you have made psos_long_names an exported
global variable. Sharing variables between two different pieces of
software is not very clean. I think it would be nicer with a get/set
function.


> diff --git a/include/psos+/psos.h b/include/psos+/psos.h
> index 32281bc..4a3921a 100644
> --- a/include/psos+/psos.h
> +++ b/include/psos+/psos.h
> @@ -197,6 +197,8 @@ u_long t_restart(u_long tid,
>
>  #include 
>
> +extern unsigned psos_long_names;
> +
>  #endif /* __KERNEL__ || __XENO_SIM__ */
>
>  /*
> diff --git a/src/skins/psos+/init.c b/src/skins/psos+/init.c
> index 978a4f1..e53967b 100644
> --- a/src/skins/psos+/init.c
> +++ b/src/skins/psos+/init.c
> @@ -26,6 +26,8 @@ int __psos_muxid = -1;
>
>  xnsysinfo_t __psos_sysinfo;
>
> +unsigned psos_long_names;
> +
>  static __attribute__ ((constructor))
>  void __init_xeno_interface(void)
>  {
> @@ -68,3 +70,14 @@ void k_fatal(u_long err_code, u_long flags)
>  {
>        exit(1);
>  }
> +
> +const char *__psos_m

[Xenomai-help] xenomai-forge: enable-smp useful?

2011-10-04 Thread Thomas De Schampheleire 
Hi,

The original Xenomai userland had to be configured explicitly with
--enable-smp if the kernel was SMP capable. The xenomai-forge
configure script still accepts this parameter.

Are we correctly assuming that this flag is no longer needed for xenomai-forge?

Thanks,
Thomas

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

[Xenomai-help] xenomai-forge [psos] t_start segmentation fault when args == NULL

2011-10-04 Thread Thomas De Schampheleire 
Hi,

In the xenomai-forge psos library, t_start() does not allow a NULL
args pointer, while I think this is allowed in PSOS.
The below code changes fix the problem.
(Note that I realize this mail is not formatted as a proper patch; if
you prefer patches for these small changes, let me know).

Best regards,
Thomas

diff --git a/lib/psos/task.c b/lib/psos/task.c
--- a/lib/psos/task.c
+++ b/lib/psos/task.c
@@ -335,10 +335,17 @@ u_long t_start(u_long tid,
return ret;

task->args.entry = entry;
-   task->args.arg0 = args[0];
-   task->args.arg1 = args[1];
-   task->args.arg2 = args[2];
-   task->args.arg3 = args[3];
+   if (args) {
+   task->args.arg0 = args[0];
+   task->args.arg1 = args[1];
+   task->args.arg2 = args[2];
+   task->args.arg3 = args[3];
+   } else {
+   task->args.arg0 = 0;
+   task->args.arg1 = 0;
+   task->args.arg2 = 0;
+   task->args.arg3 = 0;
+   }
task->mode = mode;
threadobj_start(&task->thobj);
put_psos_task(task);

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

Re: [Xenomai-help] xenomai-forge: ELF symbol interposition problems

2011-10-04 Thread Thomas De Schampheleire 
Hi,

On Tue, Oct 4, 2011 at 9:48 AM, Philippe Gerum  wrote:
> On Tue, 2011-10-04 at 09:40 +0200, Thomas De Schampheleire wrote:
>> Hi,
>>
>> We're experiencing problems with ELF symbol interposition with xenomai forge.
>> The symbol mem_alloc, declared in include/copperplate/heapobj.h and
>> defined in lib/copperplate/heapobj-malloc.c, is also present in our
>> own executable. When linking our objects with the xenomai-forge
>> libraries, the symbols from our objects take precedence.
>>
>> As a result, when heapobj_alloc() calls mem_alloc(), it calls the
>> mem_alloc from our application code, which of course is totally
>> incompatible.
>>
>> There isn't really a good solution to this problem. I think it will be
>> necessary to make sure that all exported functions from the
>> xenomai-forge libraries have a unique name. The name 'mem_alloc' (and
>> many of the functions in lib/copperplate/heapobj-malloc.c) is too
>> common.
>>
>> Another solution may be to mark certain symbols as hidden, provided
>> they do not need to be exported to applications. Some references to it
>> appear here:
>> http://www.airs.com/blog/archives/307
>>
>> What is your view on this?
>
> Restricted visibility won't work the way we want, since we have
> references to these symbols from static inlines callable from
> application code. We need a rename.

In the specific case I encountered, renaming the five mem_ functions
worked for me. I added 'heapobj_' as prefix for:
mem_destroy, mem_extend, mem_alloc, mem_free and mem_inquire.

I changed them in
include/copperplate/heapobj.h
lib/copperplate/heapobj-malloc.c

but I assume the same should be done in the other heapobj-* files.

Best regards,
Thomas

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

[Xenomai-help] xenomai-forge: ELF symbol interposition problems

2011-10-04 Thread Thomas De Schampheleire 
Hi,

We're experiencing problems with ELF symbol interposition with xenomai forge.
The symbol mem_alloc, declared in include/copperplate/heapobj.h and
defined in lib/copperplate/heapobj-malloc.c, is also present in our
own executable. When linking our objects with the xenomai-forge
libraries, the symbols from our objects take precedence.

As a result, when heapobj_alloc() calls mem_alloc(), it calls the
mem_alloc from our application code, which of course is totally
incompatible.

There isn't really a good solution to this problem. I think it will be
necessary to make sure that all exported functions from the
xenomai-forge libraries have a unique name. The name 'mem_alloc' (and
many of the functions in lib/copperplate/heapobj-malloc.c) is too
common.

Another solution may be to mark certain symbols as hidden, provided
they do not need to be exported to applications. Some references to it
appear here:
http://www.airs.com/blog/archives/307

What is your view on this?

Thanks,
Thomas

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

Re: [Xenomai-help] xenomai-forge: cast to pointer from integer of different size

2011-10-03 Thread Thomas De Schampheleire 
Hi Philippe,

On Sat, Oct 1, 2011 at 11:53 AM, Philippe Gerum  wrote:
> On Fri, 2011-09-30 at 21:53 +0200, Thomas De Schampheleire wrote:
>> Hi,
>>
>> I'm trying to compile xenomai-forge on powerpc, but am facing
>> compilation problems:
>>
>> libtool: compile:
>> /repo/tdescham/reborn/buildroot-08-eglibc-test-toolchain/output/host/usr/bin/powerpc-linux-gcc
>> -DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
>> -Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
>> -Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
>> -Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
>> -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT
>> libcopperplate_la-cluster.lo -MD -MP -MF
>> .deps/libcopperplate_la-cluster.Tpo -c cluster.c  -fPIC -DPIC -o
>> .libs/libcopperplate_la-cluster.o
>> cc1: warnings being treated as errors
>> In file included from cluster.c:89:
>> ../../include/copperplate/heapobj.h: In function 'mainheap_ptr':
>> ../../include/copperplate/heapobj.h:82: error: cast to pointer from
>> integer of different size
>> ../../include/copperplate/heapobj.h: In function 'mainheap_off':
>> ../../include/copperplate/heapobj.h:87: error: cast from pointer to
>> integer of different size
>> cc1: warnings being treated as errors
>>
>> The C library we are using for this build is eglibc.
>>
>> The offending code is:
>> static inline void *mainheap_ptr(off_t off)
>> {
>>         return off ? (void *)__memptr(__pshared_heap, off) : NULL;
>> }
>>
>> static inline off_t mainheap_off(void *addr)
>> {
>>         return addr ? (off_t)__memoff(__pshared_heap, addr) : 0;
>> }
>>
>> Since glibc/eglibc has large file support, the size of off_t is 8
>> bytes (I confirmed this from the preprocessor output).
>> However, on this 32-bit powerpc platform, a void pointer is only 4
>> bytes, hence the compiler error.
>>
>> Is my assumption correct that you are developing xenomai-forge on a
>> 64-bit platform?
>>
>
> Both on ppc 32bit and x86_64, but my ppc toolchain does not enable large
> file support.
>
>> What is the proper solution here?
>
> Use a specific memory offset type would be the best approach. I have
> committed something along these lines to the repo.

Thanks, these changes compile without problem.

Best regards,
Thomas

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

[Xenomai-help] xenomai-forge: cast to pointer from integer of different size

2011-09-30 Thread Thomas De Schampheleire 
Hi,

I'm trying to compile xenomai-forge on powerpc, but am facing
compilation problems:

libtool: compile:
/repo/tdescham/reborn/buildroot-08-eglibc-test-toolchain/output/host/usr/bin/powerpc-linux-gcc
-DHAVE_CONFIG_H -I. -I../../lib/include -O2 -D_GNU_SOURCE -D_REENTRANT
-Wall -pipe -Wstrict-prototypes -Wmissing-prototypes -Wno-long-long
-Wno-unused-parameter -Werror -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -pipe -Os -D_LARGEFILE_SOURCE
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT
libcopperplate_la-cluster.lo -MD -MP -MF
.deps/libcopperplate_la-cluster.Tpo -c cluster.c  -fPIC -DPIC -o
.libs/libcopperplate_la-cluster.o
cc1: warnings being treated as errors
In file included from cluster.c:89:
../../include/copperplate/heapobj.h: In function 'mainheap_ptr':
../../include/copperplate/heapobj.h:82: error: cast to pointer from
integer of different size
../../include/copperplate/heapobj.h: In function 'mainheap_off':
../../include/copperplate/heapobj.h:87: error: cast from pointer to
integer of different size
cc1: warnings being treated as errors

The C library we are using for this build is eglibc.

The offending code is:
static inline void *mainheap_ptr(off_t off)
{
return off ? (void *)__memptr(__pshared_heap, off) : NULL;
}

static inline off_t mainheap_off(void *addr)
{
return addr ? (off_t)__memoff(__pshared_heap, addr) : 0;
}

Since glibc/eglibc has large file support, the size of off_t is 8
bytes (I confirmed this from the preprocessor output).
However, on this 32-bit powerpc platform, a void pointer is only 4
bytes, hence the compiler error.

Is my assumption correct that you are developing xenomai-forge on a
64-bit platform?

What is the proper solution here?

Thanks,
Thomas

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

Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow

2011-09-19 Thread Thomas De Schampheleire 
Hi,

On Mon, Sep 19, 2011 at 9:42 AM, Ronny Meeus  wrote:
> On Mon, Sep 19, 2011 at 9:25 AM,   wrote:
>>> From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org]
>>> On Behalf Of Philippe Gerum
>>> Sent: Sunday, September 18, 2011 5:37 PM
>>> ...
>>> Actually, we used to follow strictly the pSOS convention for this until
>>> 2.4.x, at which point we moved to name strings precisely because
>>> non-null terminated char[4] arrays would break the registry, the way you
>>> described. This is one of the rare situations where mimicking a useless
>>> limitation of the original API may be challenged by usability concerns
>>> in the new environment, and usability won in that case. The problem
>>> mostly comes from the fact that char[4] is automatically convertible to
>>> const char *, so we have no warning/error leading us to check the
>>> potentially problematic call sites.
>>>
>>> The concern about moving back to char[4] arrays - null-terminated if
>>> shorter - is for people who currently assign strings longer than 4
>>> characters to name their objects. What could be done, is providing a
>>> build switch to select the accepted input, like
>>> --disable-psos-long-names to turn on char[4] interpretation.
>>
>> While I would prefer the switch --enable-psos-long-names, this sounds okay 
>> to me, the more so as it is more than people who use the pSOS skin without 
>> obeying pSOS rules deserve.
>> --
[..]
>>
>
> Another option would be to introduce a run-time switch.
> The default behavior could be that long names are supported and if the
> "enable_short_names()" function is called, all names will the cut at 4
> characters.
> The advantage of this dynamic switch is that different applications
> using the same library can use the mode they prefer.

I would also be in favor of a runtime setting, rather than a
compile-time one. One cannot assume that all PSOS applications on a
system follow the same rules, or that there cannot be a mix of
'legacy' PSOS applications and 'xenomai-style' ones. According to me,
a library should support all these uses.

Best regards,
Thomas

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

Re: [Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow

2011-09-19 Thread Thomas De Schampheleire 
Hi Dietmar,

On Mon, Sep 19, 2011 at 8:59 AM,   wrote:
>> From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org]
>> On Behalf Of Thomas De Schampheleire
>> Sent: Friday, September 16, 2011 3:00 PM
>> ...
>> The original PSOS interfaces that take a name (like t_create,
>> sm_create etc), expect a character array with length 4:
>> ...
>> while the corresponding PSOS skin in Xenomai expects a null-terminated
>> character array (a real string):
>> ...
>>
>> In certain situations, this difference gives rise to a buffer overflow
>> on the name variable.
>> For example:
>>
>>         unsigned long smid, err;
>>         {
>>                 char id[4] = {'S','E','M','0'};
>>                 err = sm_create(id,0,SM_PRIOR,&smid);
>>         }
>>         {
>>                 char id[4] = "SEM";
>>                 id[3] = '1';
>>                 err = sm_create(id,0,SM_PRIOR,&smid);
>>         }
>>         {
>>                 char id[4] = "SEM2";
>>                 err = sm_create(id,0,SM_PRIOR,&smid);
>>         }
>> ...
>>
>> ... The third one (SEM2)
>> is dubious because the end-of-string character will overflow the
>> array, ...
>
> This is not true, according to ISO/IEC 9899:TC3 Programming languages - C, 
> §6.7.8 Initialization:
> ...
> 14 An array of character type may be initialized by a character string 
> literal, optionally enclosed in braces. Successive characters of the 
> character string literal (including the terminating null character if there 
> is room or if the array is of unknown size) initialize the elements of the 
> array.
> ...
> 32 EXAMPLE 8 The declaration
>      char s[] = "abc", t[3] = "abc";
> defines ''plain'' char array objects s and t whose elements are initialized 
> with character string literals.
> This declaration is identical to
>      char s[] = { 'a', 'b', 'c', '\0' },
>           t[] = { 'a', 'b', 'c' };

Thanks for clarifying this...

Best regards,
Thomas

>
>> On target, this creates the following semaphores (taken from the
>> registry):
>>
>> # ls /proc/xenomai/registry/psos/semaphores/SEM*
>> ...
>> /proc/xenomai/registry/psos/semaphores/SEM0p_S22753
>> /proc/xenomai/registry/psos/semaphores/SEM1p_S22753
>> /proc/xenomai/registry/psos/semaphores/SEM2?_S22753
>>
>> As you can see, in all cases there was an array overflow (the question
>> marks correspond to non-ASCII characters), caused by the missing
>> null-termination (in itself caused by a mismatch between the original
>> PSOS interface and the Xenomai PSOS skin implementation of it).
>
> I would prefer to call this an array overrun (to distinguish the reading past 
> the end of the array here from writing past the end), even though that is not 
> a generally accepted distinction.
>
>> If you do not explicitly create a character array of length 4, e.g.
>> (char id[] = "SEM1") then the Xenomai code obviously works fine: it
>> receives a null-terminated string, as it expects.
>>
>>
>> To fix this problem, the PSOS skin should treat incoming names as
>> non-null-terminated character arrays of length 4, and explicitly add
>> null-termination before passing it to the nucleus.
>>
>> What is your view on this?
>
> I agree.
> --
> Regards,
> Dietmar
>  manroland AG Vorsitzender des 
> Aufsichtsrates: Hanno C. Fiedler Vorstand: Gerd Finkbeiner (Vorsitzender), 
> Dr. Ingo Koch, Dr. Markus Rall, Paul Steidle Sitz der Gesellschaft: Offenbach 
> am Main, Registergericht: Amtsgericht Offenbach HRB-Nr. 42592 USt-Ident-Nr. 
> DE 250200933
>
>
> ___
> Xenomai-help mailing list
> Xenomai-help@gna.org
> https://mail.gna.org/listinfo/xenomai-help
>

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

[Xenomai-help] PSOS skin: mismatch in function signatures cause buffer overflow

2011-09-16 Thread Thomas De Schampheleire 
Hi,

The original PSOS interfaces that take a name (like t_create,
sm_create etc), expect a character array with length 4:
unsigned long t_create(char name[4], unsigned long prio, unsigned long
sstack, unsigned long ustack, unsigned long flags, unsigned long
*tid);
unsigned long sm_create(char name[4], unsigned long count, unsigned
long flags, unsigned long *smid);

while the corresponding PSOS skin in Xenomai expects a null-terminated
character array (a real string):
u_long t_create(const char *name, u_long prio, u_long sstack, u_long
ustack, u_long flags, u_long *tid_r);
u_long sm_create(const char *name, u_long icount, u_long flags, u_long *smid_r);


In certain situations, this difference gives rise to a buffer overflow
on the name variable.
For example:

unsigned long smid, err;
{
char id[4] = {'S','E','M','0'};
err = sm_create(id,0,SM_PRIOR,&smid);
}
{
char id[4] = "SEM";
id[3] = '1';
err = sm_create(id,0,SM_PRIOR,&smid);
}
{
char id[4] = "SEM2";
err = sm_create(id,0,SM_PRIOR,&smid);
}
{
char id[4] = "MySemaphore";
err = sm_create(id,0,SM_PRIOR,&smid);
}

The first two examples are perfectly valid code. The third one (SEM2)
is dubious because the end-of-string character will overflow the
array, although the compiler does not complain. The fourth example
(MySemaphore) obviously is an array-overflow and is indeed warned upon
by the compiler.

On target, this creates the following semaphores (taken from the registry):

# ls /proc/xenomai/registry/psos/semaphores/SEM*
/proc/xenomai/registry/psos/semaphores/My*
/proc/xenomai/registry/psos/semaphores/MySeAB4abca
/proc/xenomai/registry/psos/semaphores/SEM0p_S22753
/proc/xenomai/registry/psos/semaphores/SEM1p_S22753
/proc/xenomai/registry/psos/semaphores/SEM2?_S22753

As you can see, in all cases there was an array overflow (the question
marks correspond to non-ASCII characters), caused by the missing
null-termination (in itself caused by a mismatch between the original
PSOS interface and the Xenomai PSOS skin implementation of it).

If you do not explicitly create a character array of length 4, e.g.
(char id[] = "SEM1") then the Xenomai code obviously works fine: it
receives a null-terminated string, as it expects.


To fix this problem, the PSOS skin should treat incoming names as
non-null-terminated character arrays of length 4, and explicitly add
null-termination before passing it to the nucleus.

What is your view on this?

Thanks,
Thomas

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

Re: [Xenomai-help] HELP: Xenomai: POSIX skin or CONFIG_XENO_OPT_PERVASIVE disabled

2010-09-14 Thread Thomas De Schampheleire 
Hi,

On Tue, Sep 14, 2010 at 1:15 PM, Zafar Iqbal
 wrote:
> Dear Sir,
>
>
> I Installed the Xenomai Successfully in MY System with Ubuntu 10.04.
> Operationg System: Ubuntu 10.4
> Xenomai Version: 2.5.4.
> refrence for the installation: 
> http://www.xenomai.org/index.php/Building_Debian_packages
>
>
>
> later I compiled the example code provided in the xenomai folder and i got 
> compiled sucessfully but while running the executable I am getting the 
> following different error:
>
> for POSIX Code:
> r...@d-3727:/usr/src/xenomai-2.5.4/examples/posix# ./satch
> Xenomai: POSIX skin or CONFIG_XENO_OPT_PERVASIVE disabled.
> (modprobe xeno_posix?)
>
> for native code
>
> r...@d-3727:/usr/src/xenomai-2.5.4/examples/native# ./rtprint
> Xenomai: native skin or CONFIG_XENO_OPT_PERVASIVE disabled.
> (modprobe xeno_native?)
> r...@d-3727:/usr/src/xenomai-2.5.4/examples/native#
>
>
> Please Suggest Me whats wrong here in the above code.

The POSIX nor native skin are currently loaded in your kernel. This
can mean that:
* you did not patch the Linux kernel correctly
* you did patch the kernel correctly, but did not enable the posix and
native skin
* you did patch the kernel correctly, compiled the respective skins as
modules, but did not load the module. In this case, as the output
suggests, you should load the kernel modules using modprobe or insmod.

Best regards,
Thomas

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