hal: Add halfileupdate to convert HAL configuration files - #4499
Open
grandixximo wants to merge 1 commit into
Open
hal: Add halfileupdate to convert HAL configuration files#4499grandixximo wants to merge 1 commit into
grandixximo wants to merge 1 commit into
Conversation
grandixximo
force-pushed
the
halfileupdate
branch
2 times, most recently
from
September 4, 2026 07:29
a157f56 to
d8e1890
Compare
Removing the 32-bit HAL types renames components, pins and parameters whose name spells a type that is gone (conv_s32_float -> conv_sint_real, mux-gen.00.in-s32-00 -> mux-gen.00.in-sint-00), so a configuration using those names fails to start. halfileupdate rewrites them. A name is rewritten only when it resolves to an instance of a component that a loadrt in the files being read created, which covers count= and names= instances and components whose HAL prefix is not the module name without guessing; a name that does not resolve is left alone and reported. Given an INI file, the HAL files it names are converted in the order LinuxCNC runs them, which is what makes a configuration convertible: its loadrt and its pin uses are regularly in different files. Keys of a user interface's own and keys outside [HAL] count, an INI value continued with a backslash is one command, and in haltcl the Tcl form 'hal setp name value' is understood as well. Signal names, aliases, comments and names built with a substitution are never rewritten. By default a diff is printed and nothing is written; --in-place rewrites atomically and keeps a .bak. The renames are tables in the tool itself, following the 64-bit only work: the eleven conv_* converters, the mux_generic and demux_generic pins, demux sel-u32 and the reset pins. They are regenerated if that set changes. No part of HAL knows the old names, and both the tool and its tables are a migration aid for one release transition, not a permanent part of HAL. The test therefore checks that the old names are gone and that what replaces them is consistent everywhere, not how any one name is spelled.
grandixximo
force-pushed
the
halfileupdate
branch
from
September 4, 2026 08:06
d8e1890 to
3d52570
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
@BsAtHome This is the .hal side of what we discussed in #4256, as a separate binary:
halfileupdate.It should be safe because it does not match strings. It reads the
loadrtlines, works out which instances exist, and converts only names that resolve to one of those instances.count=,names=(the instance name is the user's, only theloadrtline changes) and components whose HAL prefix is not the module name,mux-genand friends, all fall out of that instead of being special cases. Anything that does not resolve is left alone and reported.Given an INI file it walks the
[HAL]files in the order LinuxCNC runs them and followssource, which is the part that matters in practice: in stock configs theloadrtand the pins that use it are regularly in different files,sim_vmc.halloadsconv_float_s32 count=3andtoolchange_gray.halusesconv-float-s32.2.in. It also picks up HAL files behind a GUI's own key such asCUSTOM_HALFILE, and rewritesHALCMDlines in the INI itself. On a single .hal file it converts what that file loads and says to run the INI for the rest.Signals, aliases and comments are never rewritten, though a comment still naming something that changed is reported. Names built with a substitution or in a haltcl loop are reported rather than guessed at. Library files are skipped. Diff by default,
-ikeeps a .bak.Per your last comment: no table in
hal_lib, no hooks on the halcmd error paths, no CI mode. The renames are plain tables in the tool, taken from yourwip_hal-types-and-isolationbranch: the elevenconv_*converters, themux_genericanddemux_genericpins,demuxsel-u32and theresetpins. The four converters whose two sides collapse to one type,conv_s32_s64and friends, are gone with no replacement there, so their uses are reported instead of rewritten. I leftabs_s32,scaled_s32_sumsand the tristate pair alone since you have not renamed them; if that changes the tables get regenerated.I have not written a removal release into it, since 2.12 or 3.0 is not settled; it needs remembering at some point.
Testing: all 326 stock config INI files dry-run clean, 65 lines changed, no false positives. The test asserts that the old names are gone and that the replacements are consistent, not how they are spelled, so regenerating the tables will not invalidate it.