#linuxcnc-devel Logs

Dec 19 2023

01:05 AM pere: Can any of you explain in which commit the table end marker in docs/src/getting-started/updating-linuxcnc.adoc disappeared? I added it in 1b0a72c1f2706adf1f26b104faf9fb1f0832b328, but fail to see with 'git log -p docs/src/getting-started/updating-linuxcnc.adoc' when it was removed, which worries me.
04:47 AM -!- #linuxcnc-devel mode set to +v by ChanServ
05:38 AM rigid: andypugh: yeah, it's in linuxcnc-gbp but it's not obvious how that "linuxcnc-uspace.manpages" file gets generated to end up in the .dsc source package we upload to debian.
05:40 AM rigid: same for me. while I appreciate debian for it's role and what the community has done for FOSS in general, I hate debian with a passion. Otoh it opens up linuxcnc for a huge userbase. I suppose it wouldn't be so popular if it wasn't part of debian.
05:42 AM rigid: has Jeff Epler been highlighted somewhere? He seems to be the original author and probably knows about current packaging procedures.
05:42 AM rigid: pere: also NASA: tons of $$$$
05:44 AM pere: rigid: yes, it is expensive to developer correct code. but it is possible. :)
05:46 AM rigid: of course it's possible. I always hate when people claim "there can't be 100% secure software" it's like saying like, "chance your manual coffee mill from the last century will kill you while operation within specs is not zero."
05:47 AM rigid: NASA has a nice way of statistically dealing with failures and caring for redundancies. It's an incredible topic on it's own, how they learned from failure.
05:47 AM rigid: also regarding your commit: when in doubt: git bisect ;)
05:55 AM pere: rigid: did you get git bisect to tell you when it happened?
05:56 AM rigid: andypugh: also I think RTAI/Xenomai support should be reconsidered. RTAI is dead https://mail.rtai.org/pipermail/rtai/2023-April/028345.html while PREEMPT_RT is very alive and will be merged with mainline soonish: https://www.phoronix.com/news/Linux-6.7-printk
05:56 AM rigid: maybe even 6.8 already
05:57 AM andypugh: pere: Probably my fault, I recently had to fix a merge conflict in it.
05:57 AM andypugh: pere: Yes, sorry, here; https://github.com/LinuxCNC/linuxcnc/commit/bd1a25cbf938bc2711a220951c561bc62aaaa6a3
05:57 AM rigid: pere: yes, it tells you the first commit that doesn't pass your test (i.e. the file missing)
06:00 AM pere: andypugh: right, thanks. confused why git log -p did not show it.
06:01 AM andypugh: rigid: Alec Ari is keeping RTAI sort-of alive. https://github.com/NTULINUX
06:01 AM andypugh: (For LinxCNC specifically)
06:02 AM andypugh: Droppng it would certainly make life easier for the release manager.
06:02 AM pere: is Alec Ari able to keep doing this for long?
06:02 AM rmu: rigid: if you can't prove your software to be correct/secure how do you know it is? proof of correctness is infeasible in general for software, you can do that only for a small subset even of all correct programs.
06:06 AM andypugh: pere: I probably mistook it for the central merge-conflict marker.
06:47 AM pere: andypugh: aha. make sense. note, I am not surprised that a merge could go wrong, I am surprised that 'git log -p' do not show the change.
06:53 AM rigid: andypugh: does RTAI work with recent kernels? hm... the exact reasons why alex isn't switching to PREEMPT_RT would be interesting
06:54 AM rigid: rmu: not infeasable. things like ironclad look quite promising (and the OS project around it which I forgot the name). also there's stuff like RTEMS existing since the 90s
07:08 AM andypugh: rigid: The most recent currently supported is 5.4.258 (Which I am running bookworm on)
07:08 AM andypugh: https://www.linuxcnc.org/dists/bookworm/base/binary-amd64/
07:08 AM rigid: hm, i guess that's recent for debian standards
07:10 AM andypugh: rmu: It should work, but I think maybe only running uspace with the uspace helper. Which I don’t seem to have built or put into the repository.
07:12 AM rigid: andypugh: no, i had to setup debian here (or docker*yuck*). There's debhelper for gentoo but that's not sbuildish
07:13 AM andypugh: rmu: The RTAI uspace helper exists for 2.8 under buster https://www.linuxcnc.org/dists/buster/2.8-rtpreempt/binary-amd64/ (and I have tested it)
07:13 AM rigid: i'm currently focusing on the HAL layer (and recovering from covid - only reason why I had time to look into debian :)
07:14 AM rmu: rigid: completely off topic here, but with infeasible i mean it reduces to the halting problem and that is a fundamental roadblock
07:15 AM andypugh: rmu: Also Gödel’s Incompleteness Theorem.
07:15 AM rmu: i think i had linuxcnc / xenomai running on a asus tinkerboard at some point, but unfortunately i fried that board and SD
07:15 AM andypugh: (Which sort-of-says that purely syntactic checks can not test of correct behaviour)
07:16 AM rigid: rmu: the halting problem is an abstract thought-model. In practice it can be taimed even in complex systems. Real-world problems result from different reasons (s. infosec).
07:16 AM rmu: andypugh: yes. but in a sense those two are kinda equivalent.
07:16 AM rigid: rmu: ...but yeah, it will be the final frontier if everything else is solved
07:17 AM rigid: andypugh: gödel incompleteness only applies to a closed system. hence we have things like jtag, oscilloscopes and stuff to look from "outside the system" ;)
07:17 AM rigid: ...if I understood correctly at least
07:18 AM rmu: difficulty in proofing software correct is what shifts focus to development process
07:18 AM andypugh: Both say that you can’t judge the code by syntactic checks in the abstract case. But in systems where it is possible to test all possible sets of input configurations for correct output, you can test.
07:18 AM rigid: rmu: btw. it's very much on topic i'd say. codequality always is an issue :)
07:19 AM andypugh: (And then, of course, you can check a set of inputs, verify the code, and commit the wrong version, like I did earlier this week)
07:19 AM rigid: you can't judge the code from within it's own system... but you can with other code running outside the system
07:20 AM rigid: well, math is clearly not my main expertise.
07:20 AM * rigid should maybe read Hofstadter sometime again
07:20 AM rmu: doug hofstaedter translated that to a record player that in principle can't examine the record to exclude those that would trigger a resonance catastrophe and cause rapid unscheduled disassembly of the record player
07:20 AM andypugh: rigid: Sometimes. It’s probably not even practical to test all possile inputs for a single floating-point number. If there are two, then you can’t.
07:22 AM rigid: yeah
07:23 AM rigid: rmu: hence in practice record players aren't used to test records. Like software doesn't test itself but is tested by other software (or hardware). That's how I understood.
07:25 AM rmu: rigid: in the case of the record player, same argument applied to record tester
07:26 AM rmu: applies
07:27 AM rmu: whatever. i only wanted to say that proofing software to be "correct" is hard and infeasible in the general case. hence why process and self-limitation to "known good" techniques is important
07:28 AM rmu: usually it is even not that trivial to express what you mean with "correct" in a rigid ;) way.
07:30 AM rmu: I think xenomai should offer comparable latencies to RTAI. And it avoids running stuff in kernel mode.
07:44 AM rigid: rmu: the record tester isn't a superset of a record player for it can't play records. it's "outside the system".
07:45 AM rigid: look at ADA for formally proven software. It works.
07:45 AM rigid: yeah, personally I'd welcome any halting if it was the only problem :) tbf, halting is not really an insecure or undefined state :-P
07:51 AM rmu: rigid: the point of the halting problem is that in general you can't use software to check other software, it works only in special cases
07:52 AM rmu: first thing to do with a software checking program is to feed it itself. how can you trust the answer then.
07:54 AM andypugh: rmu: RTAI and uspace + RTAI helper doesn’t run in kernel mode either.
07:54 AM rmu: andypugh: yes, but that's not how i remember stuff being built in rtai linuxcnc.
07:55 AM andypugh: kernel-mode RTAI probably gives the best latency. Testing RTAI - LXRT on my system was OK, but not quite as good.
07:56 AM rmu: rigid: if you don't have enough headache already from recovering from covid here you can take a look at formal verification of the L4 microkernel :-) https://trustworthy.systems/research/formal-methods/
07:57 AM rmu: andypugh: getting rid of the requirement to be able to run in kernel mode would make some code cleanup / refactorings and further development of the linuxcnc realtime components way easier
07:59 AM andypugh: I am not sure that it does? The code still needs to run to completion every time, and we still can’t afford to call non thread-safe library routines.
08:02 AM -!- #linuxcnc-devel mode set to +v by ChanServ
08:05 AM rmu: e.g. it would be possible to use c++ and we could get rid of mirrored C / C++ code in HAL a usrmot
08:16 AM rmu: library routines don't need to be thread safe, they need to be bounded in runtime and are not allowed to call syscalls that will block.
08:39 AM rigid: hm, that's really confusing: "HAL components should not use underscores or “MixedCase”." is somewhat contradicting "Hyphens (“-”) separate words or fields in the same level of the hierarchy." in the HAL General Naming Conventions.
08:39 AM rigid: I mean, if I reserve hyphens to "separate words or fields" I kinda need underscore for the remaining cases where i'd use a hyphen
08:40 AM rigid: Besides excluding underscores without reason sounds a /bit/ arbitrary in times of unicode :-P
08:46 AM rigid: same with "Dots (“.”) separate levels of the hierarchy. " and the scheme "<device-name>.<device-num>.<io-type>.<chan-num>.<specific-name>"
08:46 AM rigid: so do we just separate hierarchy levels with dots or do we just separate anything?
08:47 AM rigid: not really straight forward to follow
08:48 AM rigid: or is this a bug in the docs? the scheme for function names seems to get it right
08:48 AM -!- #linuxcnc-devel mode set to +v by ChanServ
08:48 AM rmu: it's just a name, the interpretation that it's hierarchy is only on the UI side
08:49 AM rmu: there is no hierarchy in the underlying HAL pins
08:49 AM rigid: well, it's the general reference. it should be consistent otherwise no contributor can be blamed for not following it.
08:50 AM rigid: it must be a relic/bug/typo. pin names should be consistent to function names and that seems to use the dots correctly: "<device-name>-<device-num>.<io-type>-<chan-num-range>.read|write"
08:57 AM rmu: rigid: not sure where your problem is, but usually you can configure the instance name(s), and function and pin names are derived from those instance names
09:01 AM rmu: where is that naming convention spelled out? because even the basic axis sim config doesn't obey it and has ddt_x, ddt_y, comp_x, comp_y and so on components
10:58 AM rigid: rmu: no problem, but confusing. I fail to see the logic behind it, but the logic should be self-explaining ideally
10:59 AM rigid: it's spelled out here https://linuxcnc.org/docs/html/hal/general-ref.html and it doesn't surprise me no one obeys it :)
11:01 AM rigid: but it'd be nice. UIs could be simpler/more powerful with a reliable, consistent naming convention that everyone obeys. It could be tested for in CI aswell.
11:02 AM rigid: certainly not the most important issue probably... and it would have huge impact when changing all the names to be conforming. but still it'd be nice in the long run.
11:07 AM rigid: I begin to think that the real implementations might make more sense than the reference specification. e.g. digin canonical I/O type uses "digin.0.in" and "digin.0.in-not" vs. "digout.0.out" and "digout.0.invert" ...
11:08 AM rigid: why not stay consistent and use "digout.0.out-not"? and why isn't it called "not-in" and "not-out" like any sane person would call it?
11:08 AM rigid: unbelievable... totally unplayable! :)
11:34 AM rmu: 0.in / 0.in-not sorts better
12:40 PM rigid: how? there's only those two
12:44 PM rigid: but yeah, that'd at least be coherent logic
05:39 PM Unterhaus_ is now known as Unterhausen