From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4FFC50FD.7090008@xenomai.org> Date: Tue, 10 Jul 2012 17:57:49 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <4FFBEA93.5070202@xenomai.org> <4FFBF197.4050203@xenomai.org> <4FFBF7A0.7070601@xenomai.org> <4FFC43B8.2030203@xenomai.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] XDDP and inter-driver API. List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sunetra Sashi Cc: xenomai@xenomai.org On 07/10/2012 05:43 PM, Sunetra Sashi wrote: > > > On Tue, Jul 10, 2012 at 11:01 AM, Philippe Gerum > 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 > > > >> > > > > >>> > http://www.xenomai.org/________mailman/listinfo/xenomai > > > > > > > >> > > > > > > > > > >>> > > > > -- > Philippe. > > > > > > -- > Philippe. > > > > > > -- > Philippe. > > > > > > -- > Philippe. > > > -- Philippe.