#linuxcnc-devel Logs

Mar 02 2020

01:33 AM CMorley: linuxcnc-build: force build --branch=2.8
01:36 AM linuxcnc-build: you must provide a Builder, try 'force build [--branch=BRANCH] [--revision=REVISION] [--props=PROP1=VAL1,PROP2=VAL2...] <WHICH> <REASON>'
01:36 AM CMorley: linuxcnc-build: force build --branch=2.8 0000.checkin
01:36 AM linuxcnc-build: build forced [ETA 1h22m21s]
01:36 AM linuxcnc-build: I'll give a shout when the build finishes
02:23 AM linuxcnc-build: Hey! build 0000.checkin #6482 is complete: Success [3build successful]
02:23 AM linuxcnc-build: Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/6482
03:16 PM cerna: Hi, I have a very theoretical question about LinuxCNC internals. Let's say the kernel thread mode never existed and rt_preempt was the only RTOS patch supported, do you think that the RTAPI/ULAPI flags would still have a meaning (or a place in the code)?
03:40 PM andypugh: cerna: I doubt many of us have any real idea, even amongst the devs
03:40 PM andypugh: jepler has been inside rtapi, he mighr know.
04:26 PM cerna: andypugh: Hmm, kinda hoped you were experts. I am trying to wrap my head around the code and some help would be nice. Oh well...
04:26 PM andypugh: I don’t think anyone is an expert in all parts of linuxCNC.
04:27 PM cerna: It wasn't meant as a sling.
04:27 PM andypugh: I have written a few drivers and HAL components, but you don’t need to know much about the internals of RTAPI to do that, you can just use it.
04:28 PM andypugh: As I said, I think that jepler was the chap whe added preempt-rt to the rtapi, so he ought to know, but might not be paying attentiona t the moment.
04:30 PM jepler: I don't know if the #define would be the same but .. there's definitely a distinction between code that runs in the realtime process and provides realtime guarantees; and other non-realtime software in other processes.
04:37 PM cerna: Yeah, the thing is, the more I think about it, the less difference I see. The "RT" is just function which runs in constant place in thread, the userspace is another process with default scheduling.
04:37 PM cerna: BTW, "usrspace" = "non-rt".
04:37 PM cerna: * BTW, "userspace" = "non-rt".
04:39 PM jepler: maybe consider the (possibly not even implemented anyway?) rtapi_fifo_read/_write APIs. They have different behavior, because the RTAPI one must never block and the ULAPI one can. Even though they apparently have the same function signature..
04:41 PM jepler: the APIs in rtapi_parport.h are not usable except within the realtime context..
04:54 PM cerna: Maybe it is naming issue what makes it hard for me. What is RTAPI is what can be run in real-time context (can but doesn't have to, like the rtapi_parport.h), i.e. cannot sleep, cannot yield, cannot context switch and be rescheduled.
04:58 PM andypugh: rtapi is an interface layer between the rest of the code and a number of possible realtime subsystems. (including one that isn’t)
05:00 PM cerna: The basic idea and motivation is that sometime you want to serialize even non-realtime functions. Like read from modbus, do some work and write to some other device over for example USB. And I have been thinking why not use something like rtapi_app for it (maybe forked, so exit doesn't kill everything). And it just didn't click with the RTAPI/ULAPI.
06:15 PM andypugh: Interesting…. Stretch preempt-rt, master, all tests pass.
06:15 PM andypugh: But with Buster RTAI master half of them fail.
06:16 PM andypugh: I guess I should reboot to rtai and see what is going on.
06:19 PM jthornton: andypugh, should the chap that wants to translate to Chinese do a PR?
06:39 PM andypugh: I think that’s the best way
06:39 PM andypugh: That way he gets the credit..
06:40 PM jthornton: ok thanks
09:46 PM jepler: cerna: yeah, there was nothing done to make rtapi's "main loop" a reusable software library, except for running realtime stuff. It would be an interesting project...