Am 21.09.2012 um 15:21 schrieb John Kasunich: > > > 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.
I looked into this. - src/hal/components: the *.comp files have no hal_* functions and comp doesnt add any in the thread function. of the remaining 21 *.c components, at_pid.c boss_plc.c counter.c debounce.c encoder.c encoder_ratio.c freqgen.c modmath.c pid.c pwmgen.c sampler.c sampler_usr.c siggen.c sim_encoder.c stepgen.c streamer.c streamer_usr.c supply.c threads.c watchdog.c weighted_sum.c, none refers to a hal_* function in a thread function. - src/hal/drivers: use only inb/outb or device-specific functions, no hal_ functions in thread functions. - src/hal/drivers/mesanet-hostmot2: all thread functions hal_* free too. anything I missed? ------------- ok, so what do we do with this? if we want to enable the 'userland metadata for HAL' idea for the future I think it is a prerequisite to redefine the above observation as a rule, which reads: ----> no hal_ functions in thread functions whatsoever, only in init/exit code. Are we ready to commit to this? And, the turning the table: if not, what would be the use case for any hal_ function in a thread function have? I dont see any. - Michael > > > -- > 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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
