[Xenomai-help] compiling xenomai on x86_64

[Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Hi,

I'm dumb x86 user who unfortunately just seem to have tumbled in the
cross-compilation trap: I'm trying to generate i586 code on a fancy new
and fast x86_64 compilation host. I got the kernel compiled with
ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
cross tool chain), but I failed to compile xenomai against that kernel
in the following. Which magic switch do I have to apply and where?

Many thanks in advance,
Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Jan Kiszka kirjoitti:
> Hi,
> 
> I'm dumb x86 user who unfortunately just seem to have tumbled in the
> cross-compilation trap: I'm trying to generate i586 code on a fancy new
> and fast x86_64 compilation host. I got the kernel compiled with
> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
> cross tool chain), but I failed to compile xenomai against that kernel
> in the following. Which magic switch do I have to apply and where?

As dumb a guess: -m32 compiler switch?

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Heikki Lindholm wrote:
> Jan Kiszka kirjoitti:
> 
>> Hi,
>>
>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>> cross-compilation trap: I'm trying to generate i586 code on a fancy new
>> and fast x86_64 compilation host. I got the kernel compiled with
>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>> cross tool chain), but I failed to compile xenomai against that kernel
>> in the following. Which magic switch do I have to apply and where?
> 
> 
> As dumb a guess: -m32 compiler switch?
> 

Yes, I know, that would help. But where to feed this argument into the
build system?

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Jan Kiszka kirjoitti:
> Heikki Lindholm wrote:
> 
>>Jan Kiszka kirjoitti:
>>
>>
>>>Hi,
>>>
>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>cross tool chain), but I failed to compile xenomai against that kernel
>>>in the following. Which magic switch do I have to apply and where?
>>
>>
>>As dumb a guess: -m32 compiler switch?
>>
> 
> 
> Yes, I know, that would help. But where to feed this argument into the
> build system?

I would try makefile (and perhaps config/kconfig/Makefile*) and command 
line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Heikki Lindholm wrote:
> Jan Kiszka kirjoitti:
> 
>> Heikki Lindholm wrote:
>>
>>> Jan Kiszka kirjoitti:
>>>
>>>
>>>> Hi,
>>>>
>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy new
>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>> cross tool chain), but I failed to compile xenomai against that kernel
>>>> in the following. Which magic switch do I have to apply and where?
>>>
>>>
>>>
>>> As dumb a guess: -m32 compiler switch?
>>>
>>
>>
>> Yes, I know, that would help. But where to feed this argument into the
>> build system?
> 
> 
> I would try makefile (and perhaps config/kconfig/Makefile*) and command 
> line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.
>

You should be able to do that just by reconfiguring:

cd build && make reconfig CC="gcc -m32"

> -- Heikki Lindholm
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
> 


-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Philippe Gerum wrote:
> Heikki Lindholm wrote:
> 
>> Jan Kiszka kirjoitti:
>>
>>> Heikki Lindholm wrote:
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>> new
>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>> cross tool chain), but I failed to compile xenomai against that kernel
>>>>> in the following. Which magic switch do I have to apply and where?
>>>>
>>>>
>>>>
>>>>
>>>> As dumb a guess: -m32 compiler switch?
>>>>
>>>
>>>
>>> Yes, I know, that would help. But where to feed this argument into the
>>> build system?
>>
>>
>>
>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>> be sure.
>>
> 
> You should be able to do that just by reconfiguring:
> 
> cd build && make reconfig CC="gcc -m32"
> 

... would have been too easy: :-/

[after "make menuconfig ARCH=i386"]
gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
make[1]: Entering directory `/tmp/xenomai/build'
configure: error: unrecognized option: -m32
Try `/tmp/xenomai/configure --help' for more information.
make[1]: *** [config.status] Error 1
make[1]: Leaving directory `/tmp/xenomai/build'
make: *** [reconfig] Error 2

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Heikki Lindholm wrote:
>>
>>
>>>Jan Kiszka kirjoitti:
>>>
>>>
>>>>Heikki Lindholm wrote:
>>>>
>>>>
>>>>>Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>new
>>>>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>cross tool chain), but I failed to compile xenomai against that kernel
>>>>>>in the following. Which magic switch do I have to apply and where?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>As dumb a guess: -m32 compiler switch?
>>>>>
>>>>
>>>>
>>>>Yes, I know, that would help. But where to feed this argument into the
>>>>build system?
>>>
>>>
>>>
>>>I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>be sure.
>>>
>>
>>You should be able to do that just by reconfiguring:
>>
>>cd build && make reconfig CC="gcc -m32"
>>
> 
> 
> ... would have been too easy: :-/
> 
> [after "make menuconfig ARCH=i386"]
> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
> make[1]: Entering directory `/tmp/xenomai/build'
> configure: error: unrecognized option: -m32
> Try `/tmp/xenomai/configure --help' for more information.
> make[1]: *** [config.status] Error 1
> make[1]: Leaving directory `/tmp/xenomai/build'
> make: *** [reconfig] Error 2
> 

make reconfig CC="\"gcc -m32\""

(Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)

-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Heikki Lindholm wrote:
>>>
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>> new
>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>> cross tool chain), but I failed to compile xenomai against that 
>>>>>>> kernel
>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>
>>>>>
>>>>>
>>>>> Yes, I know, that would help. But where to feed this argument into the
>>>>> build system?
>>>>
>>>>
>>>>
>>>>
>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>> be sure.
>>>>
>>>
>>> You should be able to do that just by reconfiguring:
>>>
>>> cd build && make reconfig CC="gcc -m32"
>>>
>>
>>
>> ... would have been too easy: :-/
>>
>> [after "make menuconfig ARCH=i386"]
>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>> make[1]: Entering directory `/tmp/xenomai/build'
>> configure: error: unrecognized option: -m32
>> Try `/tmp/xenomai/configure --help' for more information.
>> make[1]: *** [config.status] Error 1
>> make[1]: Leaving directory `/tmp/xenomai/build'
>> make: *** [reconfig] Error 2
>>
> 
> make reconfig CC="\"gcc -m32\""
>

Please resync from the SVN head too; I've added the necessary quoting hackery 
for the above to fully work.

> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
> 


-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Philippe Gerum wrote:
> Philippe Gerum wrote:
> 
>> Jan Kiszka wrote:
>>
>>> Philippe Gerum wrote:
>>>
>>>> Heikki Lindholm wrote:
>>>>
>>>>
>>>>> Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>> Heikki Lindholm wrote:
>>>>>>
>>>>>>
>>>>>>> Jan Kiszka kirjoitti:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in
>>>>>>>> the
>>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>>> new
>>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>>> kernel
>>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes, I know, that would help. But where to feed this argument into
>>>>>> the
>>>>>> build system?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>>> be sure.
>>>>>
>>>>
>>>> You should be able to do that just by reconfiguring:
>>>>
>>>> cd build && make reconfig CC="gcc -m32"
>>>>
>>>
>>>
>>> ... would have been too easy: :-/
>>>
>>> [after "make menuconfig ARCH=i386"]
>>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>> make[1]: Entering directory `/tmp/xenomai/build'
>>> configure: error: unrecognized option: -m32
>>> Try `/tmp/xenomai/configure --help' for more information.
>>> make[1]: *** [config.status] Error 1
>>> make[1]: Leaving directory `/tmp/xenomai/build'
>>> make: *** [reconfig] Error 2
>>>
>>
>> make reconfig CC="\"gcc -m32\""
>>
> 
> Please resync from the SVN head too; I've added the necessary quoting
> hackery for the above to fully work.
> 

Great, thanks.

Now I likely run into some gcc-4 issue:

make[3]: Entering directory `/tmp/xenomai/build/skins/native/lib'
if /bin/sh ../../../libtool --mode=compile --tag=CC gcc -m32
-DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib -I../../../include
-O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__
 -march=i586 -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
-D__IN_XENO__ -Wstrict-prototypes -I../../../include
-I/tmp/xenomai/include -I/tmp/xenomai/skins/native/lib/../..    -MT
libnative_la-task.lo -MD -MP -MF ".deps/libnative_la-task.Tpo" -c -o
libnative_la-task.lo `test -f 'task.c' || echo
'/tmp/xenomai/skins/native/lib/'`task.c; \
then mv -f ".deps/libnative_la-task.Tpo" ".deps/libnative_la-task.Plo";
else rm -f ".deps/libnative_la-task.Tpo"; exit 1; fi
 gcc -m32 -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib
-I../../../include -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE
-D_REENTRANT -D__XENO__ -march=i586 -Wall -pipe -fstrict-aliasing
-Wno-strict-aliasing -D__IN_XENO__ -Wstrict-prototypes
-I../../../include -I/tmp/xenomai/include
-I/tmp/xenomai/skins/native/lib/../.. -MT libnative_la-task.lo -MD -MP
-MF .deps/libnative_la-task.Tpo -c /tmp/xenomai/skins/native/lib/task.c
 -fPIC -DPIC -o .libs/libnative_la-task.o
In file included from /tmp/linux-2.6.13.1/include/asm/math_emu.h:4,
                 from /tmp/linux-2.6.13.1/include/asm/processor.h:11,
                 from /tmp/linux-2.6.13.1/include/asm/atomic.h:6,
                 from ../../../include/nucleus/asm/atomic.h:44,
                 from /tmp/xenomai/include/nucleus/system.h:33,
                 from /tmp/xenomai/include/nucleus/asm-generic/system.h:560,
                 from ../../../include/nucleus/asm/system.h:25,
                 from /tmp/xenomai/include/nucleus/types.h:40,
                 from /tmp/xenomai/include/nucleus/queue.h:23,
                 from /tmp/xenomai/include/nucleus/timer.h:23,
                 from /tmp/xenomai/include/nucleus/thread.h:23,
                 from /tmp/xenomai/skins/native/lib/../../native/task.h:26,
                 from /tmp/xenomai/skins/native/lib/task.c:28:
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:20: error: redefinition of
struct _fpreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:25: error: redefinition of
struct _fpxreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:31: error: redefinition of
struct _xmmreg
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:35: error: redefinition of
struct _fpstate
/tmp/linux-2.6.13.1/include/asm/sigcontext.h:59: error: redefinition of
struct sigcontext

Any idea where this comes from? If not, I will dig deeper.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Jan Kiszka wrote:
> ...
> make[3]: Entering directory `/tmp/xenomai/build/skins/native/lib'
> if /bin/sh ../../../libtool --mode=compile --tag=CC gcc -m32
> -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib -I../../../include
> -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE -D_REENTRANT -D__XENO__
>  -march=i586 -Wall -pipe -fstrict-aliasing -Wno-strict-aliasing
> -D__IN_XENO__ -Wstrict-prototypes -I../../../include
> -I/tmp/xenomai/include -I/tmp/xenomai/skins/native/lib/../..    -MT
> libnative_la-task.lo -MD -MP -MF ".deps/libnative_la-task.Tpo" -c -o
> libnative_la-task.lo `test -f 'task.c' || echo
> '/tmp/xenomai/skins/native/lib/'`task.c; \
> then mv -f ".deps/libnative_la-task.Tpo" ".deps/libnative_la-task.Plo";
> else rm -f ".deps/libnative_la-task.Tpo"; exit 1; fi
>  gcc -m32 -DHAVE_CONFIG_H -I. -I/tmp/xenomai/skins/native/lib
> -I../../../include -O2 -I/tmp/linux-2.6.13.1/include -D_GNU_SOURCE
> -D_REENTRANT -D__XENO__ -march=i586 -Wall -pipe -fstrict-aliasing
> -Wno-strict-aliasing -D__IN_XENO__ -Wstrict-prototypes
> -I../../../include -I/tmp/xenomai/include
> -I/tmp/xenomai/skins/native/lib/../.. -MT libnative_la-task.lo -MD -MP
> -MF .deps/libnative_la-task.Tpo -c /tmp/xenomai/skins/native/lib/task.c
>  -fPIC -DPIC -o .libs/libnative_la-task.o
> In file included from /tmp/linux-2.6.13.1/include/asm/math_emu.h:4,
>                  from /tmp/linux-2.6.13.1/include/asm/processor.h:11,
>                  from /tmp/linux-2.6.13.1/include/asm/atomic.h:6,
>                  from ../../../include/nucleus/asm/atomic.h:44,
>                  from /tmp/xenomai/include/nucleus/system.h:33,
>                  from /tmp/xenomai/include/nucleus/asm-generic/system.h:560,
>                  from ../../../include/nucleus/asm/system.h:25,
>                  from /tmp/xenomai/include/nucleus/types.h:40,
>                  from /tmp/xenomai/include/nucleus/queue.h:23,
>                  from /tmp/xenomai/include/nucleus/timer.h:23,
>                  from /tmp/xenomai/include/nucleus/thread.h:23,
>                  from /tmp/xenomai/skins/native/lib/../../native/task.h:26,
>                  from /tmp/xenomai/skins/native/lib/task.c:28:
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:20: error: redefinition of
> struct _fpreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:25: error: redefinition of
> struct _fpxreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:31: error: redefinition of
> struct _xmmreg
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:35: error: redefinition of
> struct _fpstate
> /tmp/linux-2.6.13.1/include/asm/sigcontext.h:59: error: redefinition of
> struct sigcontext
> 
> Any idea where this comes from? If not, I will dig deeper.
> 

I just analysed this further: the problem disappears when I manually
remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
the well-known user space include issue again... ;)

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Jan Kiszka wrote:
 > I just analysed this further: the problem disappears when I manually
 > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > the well-known user space include issue again... ;)

This is wrong, the include files that should be used are those from the
Adeos/I-pipe patched 2.6 kernel you are compiling for, not those which
come from your distribution.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Jan Kiszka wrote:
>  > I just analysed this further: the problem disappears when I manually
>  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > the well-known user space include issue again... ;)
> 
> This is wrong, the include files that should be used are those from the
> Adeos/I-pipe patched 2.6 kernel you are compiling for, not those which
> come from your distribution.
> 

Yep, true. But then the build system is still somehow confused, because
it seems to include headers from both sources - otherwise I would not
see redefinitions when only asm/sigcontext.h contains the structs.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > I just analysed this further: the problem disappears when I manually
 > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > the well-known user space include issue again... ;)

I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
3.3 and 3.4, and I saw no issue with inclusions of kernel headers
from user-space. At all.

So, there is definitely something you are doing differently from me. 
If this issue is different from the '-m32' flag issue, could you please
fill a bug report, and this time, attach the exact procedure you are
following to compile (whether in-tree, or out-of-tree, whether using
configure or Kconfig, everything that would allow someone to ), the
.config and .xeno_config files you used, in order for me to be able to
reproduce the problem you observed ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > I just analysed this further: the problem disappears when I manually
>  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > the well-known user space include issue again... ;)
> 
> I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
> 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
> from user-space. At all.

I think you were lucky. As far as I remember, it is generally no good
idea to include kernel header for userspace compilation as long as you
do not _exactly_ know (or test) what they bring with them. Some
structures or defines locate in different headers under /usr/include
compared to some kernel tree. So, if you are not lucky, you drag those
definitions in twice - see below.

> 
> So, there is definitely something you are doing differently from me. 
> If this issue is different from the '-m32' flag issue, could you please
> fill a bug report, and this time, attach the exact procedure you are
> following to compile (whether in-tree, or out-of-tree, whether using
> configure or Kconfig, everything that would allow someone to ), the
> .config and .xeno_config files you used, in order for me to be able to
> reproduce the problem you observed ?
> 

As I'm not sure if you can reproduce it easily without my environment
(that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
here is a new theory:

The compilation fails in skins/native/libs/task.c (there exist similar
files in other skins as well). The error: structures in
<linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
does not tell me where the first definition was. But here is my finding:
commenting out #include <signal.h> in libs/task.c makes that error
disappear. Following the include chain of /usr/include/signal.h
(userspace headers...), you get to /usr/include/bits/sigcontext.h.
Bingo. On the x86_64 box all structs are defined here according to the
target address width. And as /usr/include/bits/sigcontext.h and
<linux>/include/asm/sigcontext.h do not exclude each other, we get
redefines.

To sum up, I still think that kernel headers need to be avoided in
userspace. Or we have to work around such issues case-by-case...

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > Gilles Chanteperdrix wrote:
 > > Jan Kiszka wrote:
 > >  > I just analysed this further: the problem disappears when I manually
 > >  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
 > >  > the well-known user space include issue again... ;)
 > > 
 > > I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
 > > 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
 > > from user-space. At all.
 > 
 > I think you were lucky. As far as I remember, it is generally no good
 > idea to include kernel header for userspace compilation as long as you
 > do not _exactly_ know (or test) what they bring with them. Some
 > structures or defines locate in different headers under /usr/include
 > compared to some kernel tree. So, if you are not lucky, you drag those
 > definitions in twice - see below.
 > 
 > > 
 > > So, there is definitely something you are doing differently from me. 
 > > If this issue is different from the '-m32' flag issue, could you please
 > > fill a bug report, and this time, attach the exact procedure you are
 > > following to compile (whether in-tree, or out-of-tree, whether using
 > > configure or Kconfig, everything that would allow someone to ), the
 > > .config and .xeno_config files you used, in order for me to be able to
 > > reproduce the problem you observed ?
 > > 
 > 
 > As I'm not sure if you can reproduce it easily without my environment
 > (that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
 > here is a new theory:
 > 
 > The compilation fails in skins/native/libs/task.c (there exist similar
 > files in other skins as well). The error: structures in
 > <linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
 > does not tell me where the first definition was. But here is my finding:
 > commenting out #include <signal.h> in libs/task.c makes that error
 > disappear. Following the include chain of /usr/include/signal.h
 > (userspace headers...), you get to /usr/include/bits/sigcontext.h.

I still do not get it: you are compiling on x86_64, so headers in
/usr/include are for x86_64, not ia32. Are you sure you do not need some
glibc-ia32-cross-devel package, or something like that ? The kernel does
not have these problems, since it is compiled with -ffreestanding.

Are you able to compile an ia32 user-space  hello world for example ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Gilles Chanteperdrix wrote:
>  > > Jan Kiszka wrote:
>  > >  > I just analysed this further: the problem disappears when I manually
>  > >  > remove any "-I<path-to-kernel-includes>" from the makefiles. Seems to be
>  > >  > the well-known user space include issue again... ;)
>  > > 
>  > > I tried to compile every kernel arch/i386 has a patch for with gcc 2.95,
>  > > 3.3 and 3.4, and I saw no issue with inclusions of kernel headers
>  > > from user-space. At all.
>  > 
>  > I think you were lucky. As far as I remember, it is generally no good
>  > idea to include kernel header for userspace compilation as long as you
>  > do not _exactly_ know (or test) what they bring with them. Some
>  > structures or defines locate in different headers under /usr/include
>  > compared to some kernel tree. So, if you are not lucky, you drag those
>  > definitions in twice - see below.
>  > 
>  > > 
>  > > So, there is definitely something you are doing differently from me. 
>  > > If this issue is different from the '-m32' flag issue, could you please
>  > > fill a bug report, and this time, attach the exact procedure you are
>  > > following to compile (whether in-tree, or out-of-tree, whether using
>  > > configure or Kconfig, everything that would allow someone to ), the
>  > > .config and .xeno_config files you used, in order for me to be able to
>  > > reproduce the problem you observed ?
>  > > 
>  > 
>  > As I'm not sure if you can reproduce it easily without my environment
>  > (that damn x86_64 gcc4 on SuSE10), I digged a little bit deeper, and
>  > here is a new theory:
>  > 
>  > The compilation fails in skins/native/libs/task.c (there exist similar
>  > files in other skins as well). The error: structures in
>  > <linux>/include/asm/sigcontext.h are being redefined. Unfortunately, gcc
>  > does not tell me where the first definition was. But here is my finding:
>  > commenting out #include <signal.h> in libs/task.c makes that error
>  > disappear. Following the include chain of /usr/include/signal.h
>  > (userspace headers...), you get to /usr/include/bits/sigcontext.h.
> 
> I still do not get it: you are compiling on x86_64, so headers in
> /usr/include are for x86_64, not ia32. Are you sure you do not need some

They are for both. You can compile some helloworld64 by calling gcc
without arguments or as easily a helloworld32 by running "gcc -m32" -
all on the same box withouth additional cross-tool stuff.

> glibc-ia32-cross-devel package, or something like that ? The kernel does
> not have these problems, since it is compiled with -ffreestanding.

...and it does not include user space headers.

> 
> Are you able to compile an ia32 user-space  hello world for example ?
> 

Yes, see above.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > They are for both. You can compile some helloworld64 by calling gcc
 > without arguments or as easily a helloworld32 by running "gcc -m32" -
 > all on the same box withouth additional cross-tool stuff.

Ok, the -m32 fix to configure.in is what I can do for now, it is in the
repository. Could you try it ?

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > They are for both. You can compile some helloworld64 by calling gcc
>  > without arguments or as easily a helloworld32 by running "gcc -m32" -
>  > all on the same box withouth additional cross-tool stuff.
> 
> Ok, the -m32 fix to configure.in is what I can do for now, it is in the
> repository. Could you try it ?
> 

Sorry, this doesn't work (but it was my first guess as well).

The problem is that "-m32" comes from the CC-overloading in
arch/i386/Makefile, and this is not visible to the grabbing trick in
configure.in. Moreover, this would not address ld and ar flags.

I'm not deep enough into this to see where one can best get the
information from. All I know is that - by chance? - RTnet's stolen build
system did not suffer from this effect the last time I checked. I think
I will have to re-check.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Jan Kiszka wrote:
>> > They are for both. You can compile some helloworld64 by calling gcc
>> > without arguments or as easily a helloworld32 by running "gcc -m32" -
>> > all on the same box withouth additional cross-tool stuff.
>>
>>Ok, the -m32 fix to configure.in is what I can do for now, it is in the
>>repository. Could you try it ?
>>
> 
> 
> Sorry, this doesn't work (but it was my first guess as well).
> 
> The problem is that "-m32" comes from the CC-overloading in
> arch/i386/Makefile, and this is not visible to the grabbing trick in
> configure.in. Moreover, this would not address ld and ar flags.
> 
> I'm not deep enough into this to see where one can best get the
> information from. All I know is that - by chance? - RTnet's stolen build
> system did not suffer from this effect the last time I checked. I think
> I will have to re-check.
> 

I know now what makes the difference: setting CC=\"$CC\" in
XENO_KBUILD_CMD. Xenomai does this and seems to override the "-m32"
extension of the kernel build system, RTnet does not.

I guess that there is a reason for passing CC to the kernel build system
and RTnet is ignoring some use case here, but then we likely have to
pass an adapted CC, just like linux/arch/i386/Makefile does.

Jan

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

[Xenomai-help] newbie question

[Ignacio García Pérez]

Hi,

I'm quite new to xenomai (switching from RTAI). I noticed that the
latency_rt.ko module fails to start the timer if the posix skin module
(xeno_posix.ko) is loaded. Is this the expected behaviour?

Thanks.

Re: [Xenomai-help] newbie question

[Jan Kiszka]

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

Ignacio García Pérez wrote:
> Hi,
> 
> I'm quite new to xenomai (switching from RTAI). I noticed that the
> latency_rt.ko module fails to start the timer if the posix skin module
> (xeno_posix.ko) is loaded. Is this the expected behaviour?
> 

Expected yes, wanted no.

Avoid xeno_posix being loaded for this test. It starts the timer when
being insmoded, while latency_rt (as a xeno_native application) does
this on program start up (and fails if it already runs).

I think I already mentioned here that I don't like this situation and
that xeno_native should provide the same timer control interface as the
other skins, didn't I? Will file a feature request now! :)

Jan


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

Re: [Xenomai-help] newbie question

[Philippe Gerum]

Ignacio García Pérez wrote:
> Hi,
> 
> I'm quite new to xenomai (switching from RTAI). I noticed that the
> latency_rt.ko module fails to start the timer if the posix skin module
> (xeno_posix.ko) is loaded. Is this the expected behaviour?
>

Yes and no. There is a change pending in my tree that makes rt_time_start() a 
bit smarter, trying its best effort to check whether the requested setting fits 
any current one, in which case the call returns without error. In the case you 
mentioned, both timer setups at nucleus level asked for oneshot, so this should 
have been ok with this patch, instead of bailing out on error rather uselessly. 
The UVM skin already enforces this for instance. I have just committed it to the 
SVN repo.

But on the long-term, I recall that Jan once asked for a normalized approach, 
allowing the timer to be set at configuration/loadup time for each skin, just 
keeping the system call as is for legacy/unusual/dynamic purposes. I agree with 
that, most of us don't really need to fiddle with the timer settings while the 
application runs, so having it statically configurable is more user-friendly and 
less error-prone.

-- 

Philippe.

Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Ignacio Garc~a P~rez wrote:
 > > Hi,
 > > 
 > > I'm quite new to xenomai (switching from RTAI). I noticed that the
 > > latency_rt.ko module fails to start the timer if the posix skin module
 > > (xeno_posix.ko) is loaded. Is this the expected behaviour?
 > >
 > 
 > Yes and no. There is a change pending in my tree that makes rt_time_start() a 
 > bit smarter, trying its best effort to check whether the requested setting fits 
 > any current one, in which case the call returns without error. In the case you 
 > mentioned, both timer setups at nucleus level asked for oneshot, so this should 
 > have been ok with this patch, instead of bailing out on error rather uselessly. 
 > The UVM skin already enforces this for instance. I have just committed it to the 
 > SVN repo.

The problem is that you also have to make the module_exit function
smarter and avoid to stop the system timer if another module is
running. This means adding a sort of reference counter to the system
timer.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newbie question

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > Ignacio Garc~a P~rez wrote:
>  > > Hi,
>  > > 
>  > > I'm quite new to xenomai (switching from RTAI). I noticed that the
>  > > latency_rt.ko module fails to start the timer if the posix skin module
>  > > (xeno_posix.ko) is loaded. Is this the expected behaviour?
>  > >
>  > 
>  > Yes and no. There is a change pending in my tree that makes rt_time_start() a 
>  > bit smarter, trying its best effort to check whether the requested setting fits 
>  > any current one, in which case the call returns without error. In the case you 
>  > mentioned, both timer setups at nucleus level asked for oneshot, so this should 
>  > have been ok with this patch, instead of bailing out on error rather uselessly. 
>  > The UVM skin already enforces this for instance. I have just committed it to the 
>  > SVN repo.
> 
> The problem is that you also have to make the module_exit function
> smarter and avoid to stop the system timer if another module is
> running. This means adding a sort of reference counter to the system
> timer.
> 

Another reason to look for a different way. The timer is a global
resource, let's manage it at a central place: the nucleus (module
parameter) plus maybe some sysfs variable. The days are over when skins
could decide about the whole system on their own ;). And it's also much
more comprehensible for the user when (s)he only has to look at one
place for tuning this parameter.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > I know now what makes the difference: setting CC=\"$CC\" in
 > XENO_KBUILD_CMD. Xenomai does this and seems to override the "-m32"
 > extension of the kernel build system, RTnet does not.

Of course ! stupid me. In makefiles, the variables assignment passed on
command line take precedence over the one made in the makefiles
themselves. And the environment variable have the least precedence, so I
guess passing CC in Kbuild environment instead of on command line should
do the trick.


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Heikki Lindholm wrote:
>>>
>>>
>>>> Jan Kiszka kirjoitti:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>> new
>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>> kernel
>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>
>>>>>
>>>>>
>>>>> Yes, I know, that would help. But where to feed this argument into the
>>>>> build system?
>>>>
>>>>
>>>>
>>>>
>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>> be sure.
>>>>
>>>
>>> You should be able to do that just by reconfiguring:
>>>
>>> cd build && make reconfig CC="gcc -m32"
>>>
>>
>>
>> ... would have been too easy: :-/
>>
>> [after "make menuconfig ARCH=i386"]
>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>> make[1]: Entering directory `/tmp/xenomai/build'
>> configure: error: unrecognized option: -m32
>> Try `/tmp/xenomai/configure --help' for more information.
>> make[1]: *** [config.status] Error 1
>> make[1]: Leaving directory `/tmp/xenomai/build'
>> make: *** [reconfig] Error 2
>>
> 
> make reconfig CC="\"gcc -m32\""
> 

Quoting - I like it...

Ok, one step further. Now I get on "make":

[...]
make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
make: invalid option -- 3
make: invalid option -- 2
Usage: make [options] [target] ...
Options:
  -b, -m                      Ignored for compatibility.
[...]
This program built for x86_64-unknown-linux-gnu
Report bugs to <bug-make@domain.hid>
make[3]: *** [xeno_hal.ko] Error 2
make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'

> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
> 

Might solve it. But meanwhile, isn't there a chance to do it as the
kernel already does within autoconf/automake?

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Jan Kiszka wrote:
>>
>>
>>>Philippe Gerum wrote:
>>>
>>>
>>>>Heikki Lindholm wrote:
>>>>
>>>>
>>>>
>>>>>Jan Kiszka kirjoitti:
>>>>>
>>>>>
>>>>>
>>>>>>Heikki Lindholm wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Jan Kiszka kirjoitti:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi,
>>>>>>>>
>>>>>>>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>>>>>>>>cross-compilation trap: I'm trying to generate i586 code on a fancy
>>>>>>>>new
>>>>>>>>and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>>>>>>>>cross tool chain), but I failed to compile xenomai against that
>>>>>>>>kernel
>>>>>>>>in the following. Which magic switch do I have to apply and where?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>As dumb a guess: -m32 compiler switch?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>Yes, I know, that would help. But where to feed this argument into the
>>>>>>build system?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>>command line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to
>>>>>be sure.
>>>>>
>>>>
>>>>You should be able to do that just by reconfiguring:
>>>>
>>>>cd build && make reconfig CC="gcc -m32"
>>>>
>>>
>>>
>>>... would have been too easy: :-/
>>>
>>>[after "make menuconfig ARCH=i386"]
>>>gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>>make[1]: Entering directory `/tmp/xenomai/build'
>>>configure: error: unrecognized option: -m32
>>>Try `/tmp/xenomai/configure --help' for more information.
>>>make[1]: *** [config.status] Error 1
>>>make[1]: Leaving directory `/tmp/xenomai/build'
>>>make: *** [reconfig] Error 2
>>>
>>
>>make reconfig CC="\"gcc -m32\""
>>
> 
> 
> Quoting - I like it...
> 
> Ok, one step further. Now I get on "make":
> 
> [...]
> make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
> make: invalid option -- 3
> make: invalid option -- 2
> Usage: make [options] [target] ...
> Options:
>   -b, -m                      Ignored for compatibility.
> [...]
> This program built for x86_64-unknown-linux-gnu
> Report bugs to <bug-make@domain.hid>
> make[3]: *** [xeno_hal.ko] Error 2
> make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'
> 
> 
>>(Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
>>
> 
> 
> Might solve it. But meanwhile, isn't there a chance to do it as the
> kernel already does within autoconf/automake?
> 

Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
-m[0-9]* to start with). Gilles, would this be ok?

-- 

Philippe.

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Philippe Gerum wrote:
 > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
 > -m[0-9]* to start with). Gilles, would this be ok?

Probably, but last time I checked that, the ppc-compiled version of the
dummy program used at configuration time to extract the arch flags from
Kbuild was not work here, because of ahem, quoting issues. There are
some -m arguments we do not want (such as for example the -msoft-float
used in ppc kernel space).

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Heikki Lindholm]

Gilles Chanteperdrix kirjoitti:
> Philippe Gerum wrote:
>  > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
>  > -m[0-9]* to start with). Gilles, would this be ok?
> 
> Probably, but last time I checked that, the ppc-compiled version of the
> dummy program used at configuration time to extract the arch flags from
> Kbuild was not work here, because of ahem, quoting issues. There are
> some -m arguments we do not want (such as for example the -msoft-float
> used in ppc kernel space).

Hmm. Does this also mean that the compiler isn't taken from kernel 
config at all? I tried compiling Xeno on a ppc box the other day, where 
the kernel had already been compiled by gcc-3.4 on another host. The box 
also had gcc-3.4, but 3.3 as the default (old debian.) Xenomai config 
seemed to pick the wrong compiler, because modules complained at load 
time of 3.3 vs. 3.4 conflict. The kernel compile host's default was 
gcc-4.0, so it was also forced to use gcc-3.4.

-- Heikki Lindholm

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Heikki Lindholm wrote:
 > Gilles Chanteperdrix kirjoitti:
 > > Philippe Gerum wrote:
 > >  > Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS (e.g. 
 > >  > -m[0-9]* to start with). Gilles, would this be ok?
 > > 
 > > Probably, but last time I checked that, the ppc-compiled version of the
 > > dummy program used at configuration time to extract the arch flags from
 > > Kbuild was not work here, because of ahem, quoting issues. There are
 > > some -m arguments we do not want (such as for example the -msoft-float
 > > used in ppc kernel space).
 > 
 > Hmm. Does this also mean that the compiler isn't taken from kernel 
 > config at all? I tried compiling Xeno on a ppc box the other day, where 
 > the kernel had already been compiled by gcc-3.4 on another host. The box 
 > also had gcc-3.4, but 3.3 as the default (old debian.) Xenomai config 
 > seemed to pick the wrong compiler, because modules complained at load 
 > time of 3.3 vs. 3.4 conflict. The kernel compile host's default was 
 > gcc-4.0, so it was also forced to use gcc-3.4.

No, it is only the hack to get the ARCH_FLAGS from kbuild system that
did not work, and now it seems to work. The Xenomai build system takes
the compiler from the CC variable, so as far as I know, the only way you
may get a different compiler when compiling the kernel and compiling
Xenomai is by having it set to a different value.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Philippe Gerum wrote:
> Jan Kiszka wrote:
> 
>> Philippe Gerum wrote:
>>
>>> Jan Kiszka wrote:
>>>
>>>
>>>> Philippe Gerum wrote:
>>>>
>>>>
>>>>> Heikki Lindholm wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Jan Kiszka kirjoitti:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Heikki Lindholm wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Jan Kiszka kirjoitti:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm dumb x86 user who unfortunately just seem to have tumbled
>>>>>>>>> in the
>>>>>>>>> cross-compilation trap: I'm trying to generate i586 code on a
>>>>>>>>> fancy
>>>>>>>>> new
>>>>>>>>> and fast x86_64 compilation host. I got the kernel compiled with
>>>>>>>>> ARCH=i386, using only the pre-installed compiler (i.e. no
>>>>>>>>> dedicated
>>>>>>>>> cross tool chain), but I failed to compile xenomai against that
>>>>>>>>> kernel
>>>>>>>>> in the following. Which magic switch do I have to apply and where?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> As dumb a guess: -m32 compiler switch?
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes, I know, that would help. But where to feed this argument
>>>>>>> into the
>>>>>>> build system?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I would try makefile (and perhaps config/kconfig/Makefile*) and
>>>>>> command line 'CC="gcc -m32" CXX="gcc -m32" make
>>>>>> menuconfig/install' to
>>>>>> be sure.
>>>>>>
>>>>>
>>>>> You should be able to do that just by reconfiguring:
>>>>>
>>>>> cd build && make reconfig CC="gcc -m32"
>>>>>
>>>>
>>>>
>>>> ... would have been too easy: :-/
>>>>
>>>> [after "make menuconfig ARCH=i386"]
>>>> gcchost2:/tmp/xenomai/build # make reconfig CC="gcc -m32"
>>>> make[1]: Entering directory `/tmp/xenomai/build'
>>>> configure: error: unrecognized option: -m32
>>>> Try `/tmp/xenomai/configure --help' for more information.
>>>> make[1]: *** [config.status] Error 1
>>>> make[1]: Leaving directory `/tmp/xenomai/build'
>>>> make: *** [reconfig] Error 2
>>>>
>>>
>>> make reconfig CC="\"gcc -m32\""
>>>
>>
>>
>> Quoting - I like it...
>>
>> Ok, one step further. Now I get on "make":
>>
>> [...]
>> make[3]: Entering directory `/tmp/xenomai/build/arch/i386/hal'
>> make: invalid option -- 3
>> make: invalid option -- 2
>> Usage: make [options] [target] ...
>> Options:
>>   -b, -m                      Ignored for compatibility.
>> [...]
>> This program built for x86_64-unknown-linux-gnu
>> Report bugs to <bug-make@domain.hid>
>> make[3]: *** [xeno_hal.ko] Error 2
>> make[3]: Leaving directory `/tmp/xenomai/build/arch/i386/hal'
>>
>>
>>> (Ok, ok, we'll get rid of autoconf for kernel modules in 2.1...)
>>>
>>
>>
>> Might solve it. But meanwhile, isn't there a chance to do it as the
>> kernel already does within autoconf/automake?
>>
> 
> Probably grabbing more stuff from the kernel cflags into XENO_ARCH_FLAGS
> (e.g. -m[0-9]* to start with). Gilles, would this be ok?
> 

Please see my bug report:

https://gna.org/bugs/index.php?func=detailitem&item_id=4546

The -m32 switch (and others) has a different origin. Have no clue how to
fix this - that's a bit too much black magic for me.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Heikki Lindholm wrote:
 > Jan Kiszka kirjoitti:
 > > Heikki Lindholm wrote:
 > > 
 > >>Jan Kiszka kirjoitti:
 > >>
 > >>
 > >>>Hi,
 > >>>
 > >>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
 > >>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
 > >>>and fast x86_64 compilation host. I got the kernel compiled with
 > >>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
 > >>>cross tool chain), but I failed to compile xenomai against that kernel
 > >>>in the following. Which magic switch do I have to apply and where?
 > >>
 > >>
 > >>As dumb a guess: -m32 compiler switch?
 > >>
 > > 
 > > 
 > > Yes, I know, that would help. But where to feed this argument into the
 > > build system?
 > 
 > I would try makefile (and perhaps config/kconfig/Makefile*) and command 
 > line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.

When using autoconf, you are not supposed to pass compiler flags in
CC, CFLAGS and CXXFLAGS are made for that... and the build system is
supposed to only touch AM_CFLAGS, so that CFLAGS is let for users, but I
am pretty sure this does not work with Xenomai, since we never tried :-)

As for the compilation for pentium on an x86_64, isn't there any
i686-linux-gcc that directly cross compiles for ia32 ?

If not, would not the following wrapper do the trick ?

#! /bin/sh
exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}

It should work with most build systems...


-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Heikki Lindholm wrote:
>  > Jan Kiszka kirjoitti:
>  > > Heikki Lindholm wrote:
>  > > 
>  > >>Jan Kiszka kirjoitti:
>  > >>
>  > >>
>  > >>>Hi,
>  > >>>
>  > >>>I'm dumb x86 user who unfortunately just seem to have tumbled in the
>  > >>>cross-compilation trap: I'm trying to generate i586 code on a fancy new
>  > >>>and fast x86_64 compilation host. I got the kernel compiled with
>  > >>>ARCH=i386, using only the pre-installed compiler (i.e. no dedicated
>  > >>>cross tool chain), but I failed to compile xenomai against that kernel
>  > >>>in the following. Which magic switch do I have to apply and where?
>  > >>
>  > >>
>  > >>As dumb a guess: -m32 compiler switch?
>  > >>
>  > > 
>  > > 
>  > > Yes, I know, that would help. But where to feed this argument into the
>  > > build system?
>  > 
>  > I would try makefile (and perhaps config/kconfig/Makefile*) and command 
>  > line 'CC="gcc -m32" CXX="gcc -m32" make menuconfig/install' to be sure.
> 
> When using autoconf, you are not supposed to pass compiler flags in
> CC, CFLAGS and CXXFLAGS are made for that... and the build system is
> supposed to only touch AM_CFLAGS, so that CFLAGS is let for users, but I
> am pretty sure this does not work with Xenomai, since we never tried :-)

Indeed. Setting CFLAGS on make overwrites a lot of important stuff, and
the compilation fails eagerly.

> 
> As for the compilation for pentium on an x86_64, isn't there any
> i686-linux-gcc that directly cross compiles for ia32 ?
> 
> If not, would not the following wrapper do the trick ?
> 
> #! /bin/sh
> exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
> 
> It should work with most build systems...
> 

Yes, this seems to work (and fail) just like the "CC=" approach.

Jan

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

Re: [Xenomai-help] compiling xenomai on x86_64

[Gilles Chanteperdrix]

Jan Kiszka wrote:
 > > #! /bin/sh
 > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
 > > 
 > > It should work with most build systems...
 > > 
 > 
 > Yes, this seems to work (and fail) just like the "CC=" approach.

Are you sure your distribution does not provide a cross-compiler ? I
worked once on an x86_64 with Fedora Core installed. And there was an
i386-linux-gcc, but it needed a special package.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] compiling xenomai on x86_64

[Jan Kiszka]

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

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > > #! /bin/sh
>  > > exec `expr "$0" : 'i686-linux-\(.*\)'` -m32r ${1+"$@"}
>  > > 
>  > > It should work with most build systems...
>  > > 
>  > 
>  > Yes, this seems to work (and fail) just like the "CC=" approach.
> 
> Are you sure your distribution does not provide a cross-compiler ? I
> worked once on an x86_64 with Fedora Core installed. And there was an
> i386-linux-gcc, but it needed a special package.
> 

Nope: OpenSuSE 10.0. Seems like there are still shortcomings of that
distribution. But I also cannot setup some kind of zoo here... :-/

Jan

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

[Xenomai-help] newbie question

[Daniele Lugli]

Hello all,
I am new to xenomai although I have already used rtai.
I see that xenomai has a user mode which looks equivalent to rtai's 
lxrt.
What about calling real-time functions implemented in a module 
(rtai_lxrt call, rt_fun_entry table and so on)?
Thank you,
Daniele Lugli

Re: [Xenomai-help] newbie question

[Philippe Gerum]

Daniele Lugli wrote:
> Hello all,
> I am new to xenomai although I have already used rtai.
> I see that xenomai has a user mode which looks equivalent to rtai's lxrt.
> What about calling real-time functions implemented in a module 
> (rtai_lxrt call, rt_fun_entry table and so on)?
> Thank you,
> Daniele Lugli
> 
> 

Have a look at the way a simple skin does it, e.g. ksrc/skins/uvm.

The UVM module exports a set of 12 syscalls, from __uvm_thread_shadow to 
__uvm_timer_tsc, as declared in include/asm-uvm/syscalls.h.

To do that, the module registers as a Xenomai skin by calling the 
xnshadow_register_interface() service, during its initialization phase. Some of 
the parameters for this function are the address and the number of entries of the 
module's syscall table.

The table is made of tuples, { <syscall-entry-addr> , <syscall-mode> }
The syscall mode bits define the operations Xenomai will do to 1) check that the 
caller is in the proper context for calling, 2) possibly switch the caller's mode 
so that the operation can be properly carried out. Switching refers to whether the 
caller must run over the real-time thread context (we call it "primary" mode), or 
may or should run over Linux directly (i.e. "secondary" mode). A terse explanation 
of the various syscall mode bits is available in include/asm-generic/syscall.h 
(i.e. __xn_exec_lostage and friends). Messing with the mode bits is the first and 
likely only cause of strange failures; be careful when setting them.

In order to issue the syscalls from user-space that will end up calling the 
routines listed in the syscall table, you will need to use the XENOMAI_SKINCALL 
macros available from include/asm-*/syscall.h depending on your arch. Have a look 
at src/skins/uvm/uvm.c to get an example of implementation. Before those syscalls 
could be invoked, your user-space program must bind to the registered skin in 
kernel space, which means getting back its internal id, so that such id could be 
specified in subsequent syscalls. This work is done in src/skins/uvm/init.c; 
intelligent paste/copy of that file will lead you rather easily to something 
working. Make sure to properly differentiate XENOMAI_SYSCALL and XENOMAI_SKINCALL. 
The former runs internal Xenomai syscalls setting up the environment for your 
application; the latter refers to the syscalls you added by mean of registering a 
new skin module.

There is no much more documentation than that for now, I'm afraid.

HTH,

-- 

Philippe.

Re: [Xenomai-help] newbie question

[Jan Kiszka]

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

Philippe Gerum wrote:
> Daniele Lugli wrote:
>> Hello all,
>> I am new to xenomai although I have already used rtai.
>> I see that xenomai has a user mode which looks equivalent to rtai's lxrt.
>> What about calling real-time functions implemented in a module
>> (rtai_lxrt call, rt_fun_entry table and so on)?
>> Thank you,
>> Daniele Lugli
>>
>>
> 
> Have a look at the way a simple skin does it, e.g. ksrc/skins/uvm.
> [...]

But before going this way, first consider what kind of functions you
exported so far via rt_fun_entry. If it was a driver API, you should
better have a look at RTDM now.

Actually, most additional APIs exported via that LXRT interface were
driver-related. But this led to rather chaotic API situation with
incompatible driver interfaces. Moreover, the often used automatic LXRT
mapping of arguments that describe large buffers was quite inefficient
(additional copy step). That is now different with both the skin and the
RTDM way under Xenomai (no automatic copying, the skin or the driver has
to take care natively).

Jan


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

Re: [Xenomai-help] newbie question

[Philippe Gerum]

Jan Kiszka wrote:
> Philippe Gerum wrote:
> 
>>Daniele Lugli wrote:
>>
>>>Hello all,
>>>I am new to xenomai although I have already used rtai.
>>>I see that xenomai has a user mode which looks equivalent to rtai's lxrt.
>>>What about calling real-time functions implemented in a module
>>>(rtai_lxrt call, rt_fun_entry table and so on)?
>>>Thank you,
>>>Daniele Lugli
>>>
>>>
>>
>>Have a look at the way a simple skin does it, e.g. ksrc/skins/uvm.
>>[...]
> 
> 
> But before going this way, first consider what kind of functions you
> exported so far via rt_fun_entry. If it was a driver API, you should
> better have a look at RTDM now.
> 

Yep. To be precise, RTDM is a particular skin in Xenomai terminology, that aims at 
providing a consistent interface and behaviour for writing real-time device 
drivers for Xenomai, so that at some point in time, we will hopefully have 
something resembling a standardized device driver factory. RTDM support is 
particularly well integrated with Xeno's POSIX real-time interface in user-space 
for instance.

-- 

Philippe.

[Xenomai-help] newbie question

[rolfetas bambolas]

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

Hi to all,
I'm trying to understand how Xenomai handles priorities, and found a paper
called "Life with Adeos" from 2005 which explains that tasks in secondary
mode force the linux kernel to inherit the RT-Tasks priority.
I also read that User-Space RT Tasks migrate to secondary mode when they
make a system call to the linux-kernel, and migrate back when they use some
Xenomai API.

Does this mean, that the Linux-Kernel will keep the inherited priority until
the RT-Task calls again Xenomai?? what happens is a RT-Task doesn't call
Xenomai for a while??
I hope you understand what I mean,
Thank you,

Rodolfo

[-- Attachment #2: Type: text/html, Size: 662 bytes --]

Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix]

rolfetas bambolas wrote:
 > Hi to all,
 > I'm trying to understand how Xenomai handles priorities, and found a paper
 > called "Life with Adeos" from 2005 which explains that tasks in secondary
 > mode force the linux kernel to inherit the RT-Tasks priority.
 > I also read that User-Space RT Tasks migrate to secondary mode when they
 > make a system call to the linux-kernel, and migrate back when they use some
 > Xenomai API.
 > 
 > Does this mean, that the Linux-Kernel will keep the inherited priority until
 > the RT-Task calls again Xenomai?? what happens is a RT-Task doesn't call
 > Xenomai for a while??
 > I hope you understand what I mean,
 > Thank you,

What you are referring to is the priority coupling between Xenomai and
Linux schedulers, and can be disabled in Xenomai configuration.

The linux kernel will keep the inherited priority until the RT-task
calls xenomai again, or until it is suspended by Linux scheduler. If the
RT-task does not call xenomai for a while (and is not suspended by Linux
scheduler), then, well, it is an RT-task after all and should be able to
run until it reaches a suspension point or wakes up another RT-task.

Note however that during this time, Linux interruptions will be allowed
to preempt the RT-task.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newbie question

[juanba romance]

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

On 8/6/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
>
> What you are referring to is the priority coupling between Xenomai and
> Linux schedulers, and can be disabled in Xenomai configuration.
>
> The linux kernel will keep the inherited priority until the RT-task
> calls xenomai again, or until it is suspended by Linux scheduler. If the
> RT-task does not call xenomai for a while (and is not suspended by Linux
> scheduler), then, well, it is an RT-task after all and should be able to
> run until it reaches a suspension point or wakes up another RT-task.

Hello both, i have a newbie doubt

What should i understand by a "xenomai" call ?
Does it simple means to call a symbol owned by the xenomai libs ?

Note however that during this time, Linux interruptions will be allowed
> to preempt the RT-task.
>
I think  that if one design a source thread/rt-task whatever which is
focused on rt constrains,
one would like to acquire ASAP the same rt-context free of such preempt
policy.
Right now i can hold a exhaustive monitoring related on my performed systems
calls
but i also suppose that at same place/time i will need some linux
service, and therefore a good practice could be quite useful, any hint
about?

Cheers

[-- Attachment #2: Type: text/html, Size: 1792 bytes --]

Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix]

juanba romance wrote:
 > On 8/6/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > >
 > >
 > > What you are referring to is the priority coupling between Xenomai and
 > > Linux schedulers, and can be disabled in Xenomai configuration.
 > >
 > > The linux kernel will keep the inherited priority until the RT-task
 > > calls xenomai again, or until it is suspended by Linux scheduler. If the
 > > RT-task does not call xenomai for a while (and is not suspended by Linux
 > > scheduler), then, well, it is an RT-task after all and should be able to
 > > run until it reaches a suspension point or wakes up another RT-task.
 > 
 > Hello both, i have a newbie doubt
 > 
 > What should i understand by a "xenomai" call ?
 > Does it simple means to call a symbol owned by the xenomai libs ?

To summarize, we could say yes. But the situation is a little bit more
complicated. Not all symbol owned by the Xenomai libs cause user-space
applications to switch to primary mode. So, an RT-task will remain in
secondary mode until it calls one of the Xenomai services which cause
their caller to switch to primary mode.

 > 
 > Note however that during this time, Linux interruptions will be allowed
 > > to preempt the RT-task.
 > >
 > I think  that if one design a source thread/rt-task whatever which is
 > focused on rt constrains,
 > one would like to acquire ASAP the same rt-context free of such preempt
 > policy.

There is an option of Xenomai which prevents Linux interruptions from
preempting an RT-task in secondary mode, it is called "interrupt shield"
but is disabled by default.

But you should understand that when you design a system "focused on rt
constraints", your rt task should remain in primary mode. When going to
secondary mode, you are loosing some determinism, because Xenomai may
have to wait an unbounded time before the migrating task is allowed to
run. Secondary mode is convenient for initializations (your system is
not yet real-time), and for tasks which live near the frontier between
real-time and non real-time world.

 > Right now i can hold a exhaustive monitoring related on my performed systems
 > calls
 > but i also suppose that at same place/time i will need some linux
 > service, and therefore a good practice could be quite useful, any hint
 > about?

The only advice I can give you is not to call directly a Linux service
from a task which is doing some real-time job. If you want to call some
linux service call it from a task which will communicate with the
real-time job using one of the IPCs proposed by Xenomai. Of course your
real-time job should not depend on timely execution of the Linux
service, otherwise you would loose determinism again.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newbie question

[Gilles Chanteperdrix]

juanba romance wrote:
 > On 8/6/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > >
 > > juanba romance wrote:
 > > > On 8/6/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > > > >
 > > > >
 > > > > What you are referring to is the priority coupling between Xenomai and
 > > > > Linux schedulers, and can be disabled in Xenomai configuration.
 > > > >
 > > > > The linux kernel will keep the inherited priority until the RT-task
 > > > > calls xenomai again, or until it is suspended by Linux scheduler. If
 > > the
 > > > > RT-task does not call xenomai for a while (and is not suspended by
 > > Linux
 > > > > scheduler), then, well, it is an RT-task after all and should be able
 > > to
 > > > > run until it reaches a suspension point or wakes up another RT-task.
 > > >
 > > > Hello both, i have a newbie doubt
 > > >
 > > > What should i understand by a "xenomai" call ?
 > > > Does it simple means to call a symbol owned by the xenomai libs ?
 > >
 > > To summarize, we could say yes. But the situation is a little bit more
 > > complicated. Not all symbol owned by the Xenomai libs cause user-space
 > > applications to switch to primary mode. So, an RT-task will remain in
 > > secondary mode until it calls one of the Xenomai services which cause
 > > their caller to switch to primary mode.
 > >
 > > >
 > > > Note however that during this time, Linux interruptions will be allowed
 > > > > to preempt the RT-task.
 > > > >
 > > > I think  that if one design a source thread/rt-task whatever which is
 > > > focused on rt constrains,
 > > > one would like to acquire ASAP the same rt-context free of such preempt
 > > > policy.
 > >
 > > There is an option of Xenomai which prevents Linux interruptions from
 > > preempting an RT-task in secondary mode, it is called "interrupt shield"
 > > but is disabled by default.
 > >
 > > But you should understand that when you design a system "focused on rt
 > > constraints", your rt task should remain in primary mode. When going to
 > > secondary mode, you are loosing some determinism, because Xenomai may
 > > have to wait an unbounded time before the migrating task is allowed to
 > > run. Secondary mode is convenient for initializations (your system is
 > > not yet real-time), and for tasks which live near the frontier between
 > > real-time and non real-time world.
 > >
 > > > Right now i can hold a exhaustive monitoring related on my performed
 > > systems
 > > > calls
 > > > but i also suppose that at same place/time i will need some linux
 > > > service, and therefore a good practice could be quite useful, any hint
 > > > about?
 > >
 > > The only advice I can give you is not to call directly a Linux service
 > > from a task which is doing some real-time job. If you want to call some
 > > linux service call it from a task which will communicate with the
 > > real-time job using one of the IPCs proposed by Xenomai. Of course your
 > > real-time job should not depend on timely execution of the Linux
 > > service, otherwise you would loose determinism again.
 > 
 > 
 > OK, I got it,
 > 
 > As i said before, right now the sources are fully controlled but the stuff
 > will grow( as always ;-) ) a lot by myself and others, therefore i need to
 > transfer this stuff ASAP to the crew in order to hold the application
 > rt-coherency.
 > Any application will read at sometime the file system and therefore we would
 > like to be in advance. Our specifications do this kind of io/ operation when
 > the system changes to the service mode, right there we need a clear
 > description about the linux and xenomai domains exchange. Now, we're not too
 > much confidence about the design capabilities to decouple both stuffs on
 > such mode, we must deeply think about...
 > 
 > Thanks a lot about your hints.

Xenomai allows you to be notified (by a signal) when a thread switches
from primary to secondary mode. For an example, see
ksrc/skins/native/snippets/sigxcpu.c

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-help] newbie question

[Philippe Gerum]

On Mon, 2007-08-06 at 19:57 +0200, Gilles Chanteperdrix wrote:
> rolfetas bambolas wrote:
>  > Hi to all,
>  > I'm trying to understand how Xenomai handles priorities, and found a paper
>  > called "Life with Adeos" from 2005 which explains that tasks in secondary
>  > mode force the linux kernel to inherit the RT-Tasks priority.
>  > I also read that User-Space RT Tasks migrate to secondary mode when they
>  > make a system call to the linux-kernel, and migrate back when they use some
>  > Xenomai API.
>  > 
>  > Does this mean, that the Linux-Kernel will keep the inherited priority until
>  > the RT-Task calls again Xenomai?? what happens is a RT-Task doesn't call
>  > Xenomai for a while??
>  > I hope you understand what I mean,
>  > Thank you,
> 
> What you are referring to is the priority coupling between Xenomai and
> Linux schedulers, and can be disabled in Xenomai configuration.
> 
> The linux kernel will keep the inherited priority until the RT-task
> calls xenomai again, or until it is suspended by Linux scheduler. If the
> RT-task does not call xenomai for a while (and is not suspended by Linux
> scheduler), then, well, it is an RT-task after all and should be able to
> run until it reaches a suspension point or wakes up another RT-task.
> 
> Note however that during this time, Linux interruptions will be allowed
> to preempt the RT-task.
> 

(unless the interrupt shield is in effect).

-- 
Philippe.