On 07/10/2012 06:15 PM, Sunetra Sashi wrote:
Thanks for clarifying. I should have said ¨not possible using Xenomai IPCs¨. Sorry about that. I am not trying to port legacy code. I am instead trying to establish a communication pathway from voice applications in user land to some real time xenomai code running within the kernel via a linux driver KM running native linux. In our instance, it is necessary that the code executes in the kernel space.
I have a very simple question: would the real-time code implement a driver?
On a related note, if I create a simple xenomai kernel module running real time code and signal events to it from linux kernel space (via the rt_event API) and communicate information back via interrupts (assuming we manage memory via shared buffers), would that considered to be a true Linux-Xenomai switch? On Tue, Jul 10, 2012 at 11:57 AM, Philippe Gerum <r...@xenomai.org <mailto:r...@xenomai.org>> wrote: On 07/10/2012 05:43 PM, Sunetra Sashi wrote: On Tue, Jul 10, 2012 at 11:01 AM, Philippe Gerum <r...@xenomai.org <mailto:r...@xenomai.org> <mailto:r...@xenomai.org <mailto:r...@xenomai.org>>> wrote: On 07/10/2012 01:23 PM, Sunetra Sashi wrote: What is the recommended methodology for kernel space modules to communicate with each other across the Linux-Xenomai space? There is no recommended methodology for this: kernel space should run within the linux domain only, or within the Xenomai domain only via the inter-driver RTDM interface, or should communicate with user-space only via a driver interface. rt <-> nrt within kernel space can be done using a low level mechanism, but there is no high level IPC for this. Again, if your kernel space code is actually an application, spare yourself a lot of pain, and move it to userland. That is interesting. So if I have a linux kernel module, say a network device driver. And another Xenomai kernel module that needs to run real time. Since we want to deal with IP packets, we need our linux module to run in the kernel space. Is it safe to assume that communication between 2 such drivers is not possible in the kernel? Where did you read the word "impossible" in any of my mails? I've been telling you two things: - the kind of interface you mention cannot be done using off-the-shelf Xenomai IPCs. It could be done with a low level interface though, hint: linux netdev interfacing to Xenomai APCs. - if your linux module actually runs an application, then you may want to consider moving it to userland, where it belongs. We strongly discourage implementing application code in kernel space. I don't know what you actually want to do, but it looks like some port of legacy code from say, VxWorks/pSOS/whatever to linux. If so, then you should reconsider your target software design, it looks wrong. There are better ways to do this, less error prone, more efficient and maintainable, provided you stop insisting on running application bits in kernel space. I corrected the rtipc rtdm device as a protocol device (I must have changed it in error) and I am able to load the xeno_rtipc.ko now. However, the socket open still fails with the same error code. Thanks I am making these calls from within the kernel, not from user space. Hence I ended up using rtdm calls instead /dev/rtp0 is a non-real-time user-space endpoint for the communication, between a regular linux application and a real-time component. It does not make sense to open it from kernel space. My intent here is to set up something similar to xddp-echo.c (RT - Non RT communication) but in kernel space instead. How should I go about creating the Linux endpoint for XDDP in the kernel? There is no direct way for that, this device/protocol is not intended for this purpose. This is a regular linux application to Xenomai real-time communication path, nothing else. Regular linux applications live in userland, only. We don't recommend building applications in kernel space. Do I need to install any specific xenomai modules for this to work? Obviously, yes. Check IPC drivers in the "Drivers" sub-menu of the Xenomai configuration. You need to have CONFIG_XENO_DRIVERS_RTIPC_XDDP enabled. I already checked this in the configuration, It is enabled. Should this also be set to y? CONFIG_XENO_DRIVERS_RTIPC. In my configuration it is set to m. Did you load the xeno_rtipc module then? It is not loaded. But I got an error when I did that. Xenomai: assertion failed at /.../kernel/xenomai/skins/) Xenomai: RTDM: missing open handler It does not make any sense. This assertion can only trigger for a named device, not a protocol device. RTIPC is a protocol device. - did you change any of the driver code? - what command did you use to load the module, verbatim? insmod: error inserting 'xeno_rtipc.ko': -1 Invalid parameters Should I see any modules loaded in /proc/xenomai/rtdm/protocol_________devices? Yes. Thanks Shweta _________________________________________________________ Xenomai mailing list Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>>>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org> <mailto:Xenomai@xenomai.org <mailto:Xenomai@xenomai.org>>>>__> http://www.xenomai.org/__________mailman/listinfo/xenomai <http://www.xenomai.org/________mailman/listinfo/xenomai> <http://www.xenomai.org/________mailman/listinfo/xenomai <http://www.xenomai.org/______mailman/listinfo/xenomai>> <http://www.xenomai.org/________mailman/listinfo/xenomai <http://www.xenomai.org/______mailman/listinfo/xenomai> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai>>> <http://www.xenomai.org/________mailman/listinfo/xenomai <http://www.xenomai.org/______mailman/listinfo/xenomai> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai>> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai> <http://www.xenomai.org/____mailman/listinfo/xenomai <http://www.xenomai.org/__mailman/listinfo/xenomai>>>> <http://www.xenomai.org/________mailman/listinfo/xenomai <http://www.xenomai.org/______mailman/listinfo/xenomai> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai>> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai> <http://www.xenomai.org/____mailman/listinfo/xenomai <http://www.xenomai.org/__mailman/listinfo/xenomai>>> <http://www.xenomai.org/______mailman/listinfo/xenomai <http://www.xenomai.org/____mailman/listinfo/xenomai> <http://www.xenomai.org/____mailman/listinfo/xenomai <http://www.xenomai.org/__mailman/listinfo/xenomai>> <http://www.xenomai.org/____mailman/listinfo/xenomai <http://www.xenomai.org/__mailman/listinfo/xenomai> <http://www.xenomai.org/__mailman/listinfo/xenomai <http://www.xenomai.org/mailman/listinfo/xenomai>>>>> -- Philippe. -- Philippe. -- Philippe. -- Philippe. -- Philippe.
-- Philippe. _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
