On Fri, Sep 21, 2012, at 05:42 AM, 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?
I don't have any ideas on that topic (and any ideas I did have would probably be massively out-of-date). The last time I gave this any thought was several years ago. I was thinking about using the /proc filesystem for user/kernel communications, but that is right about the time the Linux devs decided to deprecate /proc in favor of /sys (I think). And by now I bet they've replaced /sys with yet another flavor of the month. I hate change. > 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 Agreed. Anything that accesses metadata needs to get the mutex, which means it might block, which means it shouldn't be used from realtime threads. /src/hal/hal.h lists which functions can and cannot be used from realtime threads. I would consider that to be the most reliable source of such info, the man-page data probably came from there. I have a habit of writing the .h file first, and using it as the "document" that defines the API. > 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 suspect that this is the case, but it would require a bit of a code audit to be sure. -- John Kasunich [email protected] ------------------------------------------------------------------------------ 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
