I am sorry to be teutonic as the crowd moves on to the next most interesting feature discussion, like for instance pathnames.
-------> below is a decision item for going forward <------------ > 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, yes or no? And no, this will not resolve by hoping somehow programmers can work without a plan, or decisions, and at the end a reasonable result magically appears given a project codebase of this size. This is a fundamental change in how things are approached, and it will impact many other decisions. I have a bridge to sell to the folks who believe isolated divination is a replacement for basic planning and coordination. Any board members around who feel it is part of their role to exert some stewardship about long-term issues - please speak up. - Michael Am 23.09.2012 um 19:14 schrieb Michael Haberler: > > 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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
