On Fri, 21 Sep 2012 11:42:59 +0200, Michael Haberler wrote: > Am 21.09.2012 um 10:43 schrieb EBo: > >> On Fri, 21 Sep 2012 10:28:20 +0200, Michael Haberler wrote: >>> >>> ... >>> >>> the tough question to which I dont have a good answer yet: how will >>> kernel RT components access hal_* functions if they vanish from the >>> common RTAPI/ULAPI code and migrate to userland completely? I've >>> read >>> through >>> >>> >>> http://people.ee.ethz.ch/~arkeller/linux/multi/kernel_user_space_howto.html#toc7 >>> but none of the options there strikes me as the obvious method. Any >>> suggestions? >> >> A couple of things I wanted to play with are the 9p file system >> primitives recently ported to Linux. I am not sure that the >> advanced >> distributed locks have yet been ported, but I should be able to set >> up >> some simplified examples. The real question is when I will have >> time to >> do this... > > EBo, > > I would be surprised if any 9p kernel primitives can be used from an > RTAI (disguised through RTAPI) thread - which is the hard question > for > the above problem; once you're in a normal Linux (non-RTAI-thread) > kernel context there's a multitude of mechanisms to choose from > > it boils down to functions like > http://www.linuxcnc.org/docs/devel/html/man/man3/hal_link.3hal.html > which can currently be used from userland through ULAPI, from the > normal Linux kernel context during init and cleanup of a module, AND > an RTAI thread > > see for instance > http://www.linuxcnc.org/docs/devel/html/man/man3/hal_exit.3hal.html > 'Realtime considerations' which spells out restrictions on some of > these functions - not all of them need to be RTAI-thread capable > > - Michael > > ps: actually - which ones of the hal_* or underlying RTAPI functions > absolutely MUST be RTAI/RTAPI-thread compatible because they are > actually used in thread functions? it seems to me fiddling with named > HAL objects from threads is not a good idea to start with > > http://www.linuxcnc.org/docs/devel/html/man/man3/intro.3rtapi.html > hints that it's quite few of them like for example rtapi_inb(3) which > would be irrelevant for HAL metadata management > > if it turns out that ALL the HAL object/metadata management functions > would be used init/cleanup and ULAPI ONLY this would simplify the > problem considerably
I have not been keeping close tabs on how the new 9p stuff is doing, but I suspect that the kernel version lag with RTAI is a no go. I was thinking in terms of PREEMPT-RT first, and then see what it will take to back port to the RTAI version (or forward port RTAI to a much newer kernel). As for realtime... When I was interning at IBM they had a test of the 9p protocol implemented on the new Bluegene/Q processors - they were able to turn on the connection between two processors and send a full handshake in 720 ns. The actual message passing is a small part of that. I also know that 9p has been used in a number of robotics projects, but I have not had any direct experience to date with these. The idea I wanted to play with was to establish a distributed hal file system via 9p. Before getting to far along those lines though I need to see if anyone has ported the user definable namespaces to Linux yet. I actually want/need that for my thesis work. EBo -- ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
