Re: [Xenomai] Context switching with POSIX skin

[Greg Gallagher]

I was able to reproduce the issue, but it only happened if I didn't
have the driver loaded.  I would try building it as a loadable module
then load it and confirm it's running using lsmod.  Then run your test
application.

-Greg

On Mon, Apr 9, 2018 at 11:13 PM, Greg Gallagher  wrote:
> That looks sane to me, this thread outlines a similar problem:
>
> http://xenomai.org/pipermail/xenomai/2017-December/038078.html
>
> My CFLAGS and LDFLAGS are slightly different:
>
> XENO_CONFIG := $(PATH_TO_STAGE)/usr/xenomai/bin/xeno-config
> CFLAGS := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --posix --cflags)
> LDFLAGS := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --posix --ldflags)
> CC := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --cc)
>
> PATH_TO_STAGE for my environment points to where I installed my xeno
> binaries in during the build stage.
>
> -Greg
>
> On Mon, Apr 9, 2018 at 5:59 AM,   wrote:
>> Quoting Greg Gallagher :
>>
>>> Tested on zynq zybo and microzed, the demo works. I built it from stable
>>> using the 4.14 ipipe-arm repo and modprobed the module at boot. Are you
>>> using a module or building it into the kernel?
>>>
>>> -Greg
>>
>>
>> I'm building it into the kernel. Since I'm new to all these I just took an
>> already working Ubuntu 16.04 with Xenomai 3.0.5 and added to its .config
>> file
>> the RTIPC option with gconfig. The resulting .config has the following
>> lines:
>>
>> #
>> # Real-time IPC drivers
>> #
>> CONFIG_XENO_DRIVERS_RTIPC=m
>> CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
>> CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
>> CONFIG_XENO_OPT_IDDP_NRPORT=32
>> CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
>> CONFIG_XENO_OPT_BUFP_NRPORT=32
>>
>> After compiling the new kernel and installing it, if I do modprobe -n -v
>> xeno_rtipc I get:
>>
>> insmod /lib/modules/4.9.90/kernel/drivers/xenomai/ipc/xeno_rtipc.ko
>>
>> So since it seems to be correctly installed I guess it may a problem with
>> my Makefile, I'm using:
>>
>> target = xddp-echo
>> skin = posix
>> CC := $(shell /usr/xenomai/bin/xeno-config --cc)
>> CFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --cflags)
>> LDFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --ldflags)
>> $(target): $(target).c
>> $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
>> clean:
>> @rm $(target)
>>
>> Am I missing something?
>>
>> - Rodrigo
>>
>>
>>

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Context switching with POSIX skin

[Greg Gallagher]

That looks sane to me, this thread outlines a similar problem:

http://xenomai.org/pipermail/xenomai/2017-December/038078.html

My CFLAGS and LDFLAGS are slightly different:

XENO_CONFIG := $(PATH_TO_STAGE)/usr/xenomai/bin/xeno-config
CFLAGS := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --posix --cflags)
LDFLAGS := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --posix --ldflags)
CC := $(shell DESTDIR=$(PATH_TO_STAGE) $(XENO_CONFIG) --cc)

PATH_TO_STAGE for my environment points to where I installed my xeno
binaries in during the build stage.

-Greg

On Mon, Apr 9, 2018 at 5:59 AM,   wrote:
> Quoting Greg Gallagher :
>
>> Tested on zynq zybo and microzed, the demo works. I built it from stable
>> using the 4.14 ipipe-arm repo and modprobed the module at boot. Are you
>> using a module or building it into the kernel?
>>
>> -Greg
>
>
> I'm building it into the kernel. Since I'm new to all these I just took an
> already working Ubuntu 16.04 with Xenomai 3.0.5 and added to its .config
> file
> the RTIPC option with gconfig. The resulting .config has the following
> lines:
>
> #
> # Real-time IPC drivers
> #
> CONFIG_XENO_DRIVERS_RTIPC=m
> CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
> CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
> CONFIG_XENO_OPT_IDDP_NRPORT=32
> CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
> CONFIG_XENO_OPT_BUFP_NRPORT=32
>
> After compiling the new kernel and installing it, if I do modprobe -n -v
> xeno_rtipc I get:
>
> insmod /lib/modules/4.9.90/kernel/drivers/xenomai/ipc/xeno_rtipc.ko
>
> So since it seems to be correctly installed I guess it may a problem with
> my Makefile, I'm using:
>
> target = xddp-echo
> skin = posix
> CC := $(shell /usr/xenomai/bin/xeno-config --cc)
> CFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --cflags)
> LDFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --ldflags)
> $(target): $(target).c
> $(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
> clean:
> @rm $(target)
>
> Am I missing something?
>
> - Rodrigo
>
>
>

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Henning Schild]

Am Fri, 6 Apr 2018 17:33:20 +0200
schrieb Leopold Palomo-Avellaneda :

> Hi,
> 
> On 06/04/18 10:47, Henning Schild wrote:
> 
> [...]
> 
> >>  >Thanks for sharing this. IIRC, we have some Xeommai user
> >>  >in-house as well who looked into cmake, need to check the status
> >>  >and scope again (maybe Henning knows more). Could be
> >>  >interesting, indeed.
> >>
> >> If I may ask, are you using the "boostraps" from Xenomai or some
> >> own init-code? (that’s currently the biggest headache remaining)  
> > 
> > No, i do not know anyone using CMake with Xenomai, so i would not
> > know how to deal with bootstrap there.  
> 
> I use CMake ...
> 
> >>  >
> >>  >For my understanding: You need cmake upstream changes to make
> >>  >things work? Or is this project something that could eventually
> >>  >be carried in Xenomai upstream, just requiring some cmake
> >>  >version >= X?
> >>
> >> No strict need to upstream the scripts in either Xenomai or CMake,
> >> the files just need to be in the search-path of CMake to be usable
> >> (likely doesnt need anything newer than CMake 3.0 but would need to
> >> test this). I value the feedback from both communities,
> >> particularly because I don’t use anything but the Posix/Cobalt
> >> Skin and getting it into CMake would be the best thing for
> >> maintenance.  
> > 
> > It would probably be a good idea to try and mainline it in one of
> > the two projects. And my guess is that CMake would not really fit
> > and they might not want such code.
> >   
> >> Nevertheless it could be really helpful to add a headerfile in the
> >> Xenomai distribution, replicating the steps that
> >> 'boilerplate/init/bootstrap.c' does, and allowing to disable parts
> >> of the functionality like the main wrapper. That glue code would
> >> ideally be built together with libraries/executables using it
> >> (identical flags and such). Right now the code is mostly
> >> duplicated and placed with the CMake Scripts, which is not ideal.  
> > 
> > I did not fully understand the bootstrap with regard to cmake yet.
> > But the magic wrapping is not pretty, also in other regards. So
> > patches that improve that, while actually targeting something like
> > CMake, would be welcome.  
> 
> Maybe I didn't understood deeply the problem here, but when I switch
> to Xenomai -3 I got it.
> 
> When you were working with Xenomai-2, and you create your program,
> then using xeno-config you could obtain your main information to
> compile and link.
> 
> So, if you want to build your posix program, xeno-config gave you:
> 
> $ xeno-config --skin posix --ldflags
> -Wl,@/usr/lib/x86_64-linux-gnu/posix.wrappers
> -L/usr/lib/x86_64-linux-gnu -lpthread_rt -lxenomai -lpthread -lrt
> 
> $ xeno-config --skin posix --cflags
> -I/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -D__XENO__
> -I/usr/include/xenomai/posix
> 
> 
> With Xenomai-3, you obtain similar parameters with cflags:
> 
> $ xeno-config --skin posix --cflags
> -I/usr/include/xenomai/cobalt -I/usr/include/xenomai -g -O2
> -fdebug-prefix-map=/build/xenomai-3.0.6+ds2rtnet=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE
> -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__
> -D__COBALT_WRAP__
> 
> But, ldflags:
> 
> $ xeno-config --skin posix --ldflags
> -Wl,--no-as-needed -Wl,@/usr/lib/x86_64-linux-gnu/cobalt.wrappers
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
> -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread
> 
> Here note that to your program you must add and object:
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o
> 
> that depends on the --auto-init|auto-init-solib|no-auto-init option
> and could be:
> 
> - none (--no-auto-init)
> - bootstrap-pic.o (--auto-init-solib)
> - bootstrap.o (--auto-init or default)
> 
> To me the questions then are:
> - The code there could be encapsulated in a header?
> - or could be put in a lib?
> - only could be done in this way?

Ok, i am starting to understand the issue here. A lib or header sounds
good, if that can be done.

> Regarding to CMake, I solved this passing this arguments to VARS to
> cmake. So, tge FindXenomai was a simple wrapper to xeno-config to
> obtain the correct values to build the xeno application.
> 
> If my memory doesn't fail it was something that Gilles recommend some
> years ago. The best way to build a xenomai application is to use the
> xeno-config output to obtain the correct values.

Yes, no matter what build system you should call xeno-config from it,
and not copy and paste its output around.

> So, my point of view is that you don't have to modify anything from
> Xenomai to use it with CMake. Another thing is the bootstrap stuff
> that maybe it's a bit ugly.
>
> 
> > Now regarding 

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Henning Schild]

Am Fri, 6 Apr 2018 17:37:06 +0200
schrieb Leopold Palomo-Avellaneda :

> Hi
> 
> On 06/04/18 11:36, Lange Norbert wrote:
> [...]
> 
> > 
> > Google for "FindXenomai" to see that I am hardy the only one with
> > that need. What I would like is to have a proper solution for
> > Xenomai, and my way of doing that is to get criticized from
> > people-in-the-know.  
> 
> I have done a "FindXenomai" and I have found several projects. I did
> myself one, based in the ROS one, and the Orocos people has another
> for instance.
> 
> You are not alone in the darkness ... ;-)

Ok, then go ahead and share it, at least with Norbert.

Henning

> 
> Leopold
> 
> 


___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] Context switching with POSIX skin

[rodrigo . amaducci]

Quoting Greg Gallagher :

Tested on zynq zybo and microzed, the demo works. I built it from  
stable using the 4.14 ipipe-arm repo and modprobed the module at  
boot. Are you using a module or building it into the kernel?


-Greg


I'm building it into the kernel. Since I'm new to all these I just took an
already working Ubuntu 16.04 with Xenomai 3.0.5 and added to its .config file
the RTIPC option with gconfig. The resulting .config has the following lines:

#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=m
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32

After compiling the new kernel and installing it, if I do modprobe -n -v
xeno_rtipc I get:

insmod /lib/modules/4.9.90/kernel/drivers/xenomai/ipc/xeno_rtipc.ko

So since it seems to be correctly installed I guess it may a problem with
my Makefile, I'm using:

target = xddp-echo
skin = posix
CC := $(shell /usr/xenomai/bin/xeno-config --cc)
CFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --cflags)
LDFLAGS := $(shell /usr/xenomai/bin/xeno-config --skin=$(skin) --ldflags)
$(target): $(target).c
$(CC) -o $@ $< $(CFLAGS) $(LDFLAGS)
clean:
@rm $(target)

Am I missing something?

- Rodrigo




___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai

Re: [Xenomai] building Xenomai Apps with CMake (RFC)

[Lange Norbert]

>- none (--no-auto-init)
 >- bootstrap-pic.o (--auto-init-solib)
 >- bootstrap.o (--auto-init or default)
 >
 >To me the questions then are:
 >- The code there could be encapsulated in a header?
I dont see how it could not, it just uses public API
 >- or could be put in a lib?
As static lib: Not a good idea, as you would then need to pull the code in (ld 
just links objects which have referenced symbols)
As dynamic lib: Not entirely possible, and even less flexible than now. However 
helper-code should be put there (parsing "/proc/self/cmdline")
 >- only could be done in this way?

I actually added the "regular" booststrap linking in the object file,
https://github.com/nolange/cmake_xenomai/blob/master/examples/posix/cyclictest/CMakeLists.txt
Note that this will automatically decide whether to use the bootstrap.o or 
bootstrap-pic.o variant.

But I don’t like how this is done. You could use any kind of different 
compilerflags,
and separating the "bootstrapping" itself (configuring Xenomai + promoting the 
main thread)
from the "other" stuff (handling "--help" and adding a main method) would give 
you
a lot flexibility.

>Regarding to CMake, I solved this passing this arguments to VARS to cmake. So,
 >tge FindXenomai was a simple wrapper to xeno-config to obtain the correct
 >values
 >to build the xeno application.

The VARS approach is fragile, and won't play nice if you have a project
where you build multiple apps/libraries - some not using Xenomai.
Just think of unit-tests that run on plain Linux.
The "modern" CMake approach is to expose targets you can link to.

 >
 >If my memory doesn't fail it was something that Gilles recommend some years
 >ago.
 >The best way to build a xenomai application is to use the xeno-config output 
 >to
 >obtain the correct values.

The best way ist to "concentrate" the knowledge in the Xenomai project,
so Xenomai-4 will (hopefully) just build with your project.
This does not have to be isolated to xeno-config, which has some problems
If you have a relocatable build environment (and should not contain baseline 
and optimization  flags from the toolchain)

 >
 >So, my point of view is that you don't have to modify anything from Xenomai to
 >use it with CMake. Another thing is the bootstrap stuff that maybe it's a bit
 >ugly.

No, you don't have to, but some changes could make it more robust,
namely putting the bootstrap functionality in a header
and having the flags accessible without needing to execute a tool (even if it’s 
a shell-script).

I am still torn between whether a FindXenomai would be fitting better in CMake 
or Xenomai.

In CMake it would be easy to use, even with already released Xenomai Versions,
and easy to just add into your own project so you don’t need a not-yet-released 
CMake.
It might totally break down in the future, should Xenomai (4) have drastical 
changes.

In Xenomai, it would be easier to maintain and getting out information like the 
version
could be just ironed in when installing. It would need more changes to Xenomai 
however,
and this doesn’t help anyone with an already released version, so you will need 
an additional
Method of supporting those.

Norbert


This message and any attachments are solely for the use of the intended 
recipients. They may contain privileged and/or confidential information or 
other information protected from disclosure. If you are not an intended 
recipient, you are hereby notified that you received this email in error and 
that any review, dissemination, distribution or copying of this email and any 
attachment is strictly prohibited. If you have received this email in error, 
please contact the sender and delete the message and any attachment from your 
system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You

___
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai