Draft - HAL types update and HAL isolation#4247
Conversation
7bb25b0 to
c4f0b6f
Compare
|
On Fr, 2026-07-17 at 07:08 -0700, Luca Toniolo wrote:
grandixximo left a comment (LinuxCNC/linuxcnc#4247)
Never cease to amaze me...
Are we having a meeting with #4099 as central discussion? We skipped
a few weeks, not sure why @rmu75
Seems about time... or is everyone on summer vacation? Probably
better send to the mailing list...
I had some unexpected troubles with "remote" internet access around
21st of june and it seems I got a bit sidetracked... sorry for that.
Last meeting I have notes for was 2026-06-07 10:00 CEST
According to our cadence, 2026-06-21 would have been late, 2026-07-05
early and the next meeting would be tomorrow "late" at 20:00 CEST.
I'm not sure I can make it this weekend but I will try.
I think luca wants to discuss the hal interface redesign, so maybe
change of plan and meeting at 10:00 would be better? please reply
whoever can make it at what time.
https://greenlight.bbb.uni-rostock.de/b/ste-c4d-brs-3k6
Access code: 869782
(hope this is still active)
best regards
…--
Robert Schöftner ***@***.***>
|
|
Should send to the mailing list, my bad for starting it here 😞 |
c4f0b6f to
bce8942
Compare
|
@grandixximo the whole |
2f2ddb5 to
64739e1
Compare
|
Thanks for the quick turnaround, checked the new push. The Two Out-of-Bounds of the same family as ADDF remain:
Minor: literal Loadusr: agreed, the whole path wants a proper rewrite, here or in a follow up. |
64739e1 to
695ac8f
Compare
|
Should be all fixed now, except the param write in hal_set_p, which will take more than a mere moment to alter. |
c6f9e2d to
7f5b5ae
Compare
|
I just tested this branch on a machine with smartserial slaves. the driver loads, and creates all the pins, but nothing works. IO are not getting to the hardware. I cannot see any error messages. |
Thanks for testing. But, I haven't run locally on the hardware for some time. Need to check up on that. Also, the changes in hostmot2 have not yet been properly reviewed, so there can be lurking any detail in any layer of the hm2 driver stack. I'll give a peep when this can be tested again. |
7f5b5ae to
6d5e2e2
Compare
|
Does your test config string enable absenc (ssi/biss/fanuc formats)? |
Out-of-tree .comp components using the legacy HAL types (float, bit, s32, u32, s64, u64, signed, unsigned) and direct pin/param assignment stop working when the HAL API break is performed (LinuxCNC#4099, LinuxCNC#4247). halcompupdate rewrites them to the new API automatically: * declaration types are converted: float->real, bit->bool, s32->si32, u32->ui32, s64->sint, u64->uint, signed->si32, unsigned->ui32 ('port' is left alone, it has no new-style replacement yet) * writes to out/io pins and to params become <name>_set(...) calls, including compound assignments, ++/--, array pins, chained assignments, *<name>_ptr dereferences and writes inside #define macros (macro parameters shadow same-named pins) * legacy C types are modernized (double/real_t -> rtapi_real, hal_bit_t -> volatile rtapi_bool, ...) * reads are unchanged and pins are never renamed, so existing HAL configurations keep working Constructs that cannot be converted safely are left unchanged with a warning for manual conversion: taking the address of a pin/param, direct use of the legacy hal_pin_*_new/hal_param_*_new creation API, postfix ++/-- whose value is used, and array indices with side effects. In-place rewriting is atomic (temp file + rename) and keeps a .bak backup created with O_EXCL|O_NOFOLLOW. halcompile now warns once per deprecated type, pointing to halcompupdate(1), at the spot previously marked for this warning. Docs: migration section in comp.adoc, new halcompupdate(1) manpage, SEE ALSO in halcompile(1). Regression test in tests/halcompile/update-api. Validated by converting all in-tree components from master: 119/124 compile (the other 5 need in-tree headers and fail identically for the already-converted versions), and the output matches the hand conversions in LinuxCNC#4247 functionally.
6d5e2e2 to
ce3117d
Compare
Out-of-tree .comp components using the legacy HAL types (float, bit, s32, u32, s64, u64, signed, unsigned) and direct pin/param assignment stop working when the HAL API break is performed (LinuxCNC#4099, LinuxCNC#4247). halcompupdate rewrites them to the new API automatically: * declaration types are converted: float->real, bit->bool, s32->si32, u32->ui32, s64->sint, u64->uint, signed->si32, unsigned->ui32 ('port' is left alone, it has no new-style replacement yet) * writes to out/io pins and to params become <name>_set(...) calls, including compound assignments, ++/--, array pins, chained assignments, *<name>_ptr dereferences and writes inside #define macros (macro parameters shadow same-named pins) * legacy C types are modernized (double/real_t -> rtapi_real, hal_bit_t -> volatile rtapi_bool, ...) * reads are unchanged and pins are never renamed, so existing HAL configurations keep working Constructs that cannot be converted safely are left unchanged with a warning for manual conversion: taking the address of a pin/param, direct use of the legacy hal_pin_*_new/hal_param_*_new creation API, postfix ++/-- whose value is used, and array indices with side effects. In-place rewriting is atomic (temp file + rename) and keeps a .bak backup created with O_EXCL|O_NOFOLLOW. halcompile now warns once per deprecated type, pointing to halcompupdate(1), at the spot previously marked for this warning. Docs: migration section in comp.adoc, new halcompupdate(1) manpage, SEE ALSO in halcompile(1). Regression test in tests/halcompile/update-api. Validated by converting all in-tree components from master: 119/124 compile (the other 5 need in-tree headers and fail identically for the already-converted versions), and the output matches the hand conversions in LinuxCNC#4247 functionally.
7de3e27 to
9783519
Compare
9783519 to
ce7a050
Compare
ce7a050 to
2b8cd3f
Compare
This is the full tree conversion for the HAL types where #4099 would be the first step.
Changes:
State of progress of these changes:
Missing in this tree: